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Preface 



In this global society, manufacturers compete in many ways, and information 
infrastructures play a critical role in ensuring the right information is available at 
the right time and the right place to support informed decision making. The 
traditional approach that assumes all information can be located on a single 
mainframe and accessed by everybody in the enterprise has fallen by the wayside, 
and new infrastructures supporting extended or virtual enterprises and globally 
distributed supply chains are becoming increasingly vital to successful, 
competitive organizations. Functions, data, and information must be made be 
available to all without regard to location, accessibility, or the ability to view in a 
native format. 

This book is a result of a conference, which brought together a number of leading 
experts from around the world that work on topics related to the design, 
implementation, and use of information infrastructures for manufacturing. These 
experts presented their views on the state of the art, and on a wide variety of topics 
related to the title. The topics range from the establishment of a generic enterprise 
framework, which can be used for the design of a supporting information 
infrastructure to details of how geometric surfaces should be merged together. 
Although not an exhaustive publication, we believe that the publications in this 
book represent the state of the art in this research is essential reading for anyone 
who is attempting the design or development of an information infrastructure for 
all aspects of Manufacturing. 

Each of the chapters present related presentations given by the authors at the third 
international conference on the Design of Information Infrastructure Systems for 
Manufacturing (DIISM ‘98) held at The University of Texas at Arlington’s 
Automation & Robotics Research Institute (ARRI) in Fort Worth, TX from 
May 18-22, 1998. The conference was sponsored by the International Federation 
of Information Processing (IFIP) through Working Groups 5.3 (Computer Aided 
Manufacturing) and 5.7 (Computer Applications in Production Management). 
Other sponsors included the National Institute of Standards and Technology, 
Gaithersburg, MD, USA, and the CALS Connectivity Center of Fort Worth, TX, 
USA. 

We sincerely thank all the authors, the program committee members and the 
conference participants for their contribution to the conference and this book. 




Special thanks goes to the members of the organizing committee, especially 
Ms. Kathleen Elfrink, Ms. Raynette Taylor, and Mr. Larry Whitman whose hard 
work and dedication contributed greatly to the success of the conference and the 
publication of this book. We would like to extend an additional thank you to 
Ms. Elfrink for her tenacity in preparing the final manuscript for publication. We 
also gratefully acknowledge the strong support of Dr. Jan Goossenaerts and 
Dr. Hans Woitman, who organized DIISM ‘96. 

In conclusion, we hope that this book will be a useful source of knowledge on the 
state of the art and practice on Information Infrastructures for Manufacturing and 
that the issues and questions raised within stimulate further research into this 
fascinating topic. 



John Mills, Fort Worth, Texas 
Fumihiko Kimura, Tokyo, Japan 




Introduction: Towards an information 
infrastructure for manufacturing industry 

Accelerating change, rapidly expanding access to technology, globalization of 
markets and competition, increasing customer expectations and ubiquitous 
availability and distribution of information are all drivers for today's 
Manufacturers. 

Companies are responding to these pressures by focusing on their core 
competencies and continually seeking new approaches to improving 
responsiveness. They are forming new strategic alliances with other organizations 
possessing complementary core competencies needed to meet fleeting market 
demands. Organizational strategies include virtual and extended enterprises, 
improved supply chain management and optimization, integrated yet distributed 
(across the extended enterprise) product and process development, and increased 
digitalization of product and process data. Because of the shortening life cycle, 
these alliances may last no longer than a few months before a new alliance to 
address a new market opportunity become necessary. Time to market is an ever- 
increasing major competitive advantage 

Information and Communication Technologies (ICT) are emerging as a critical 
technology component of forward looking companies. In the environment of 
constant and often unanticipated change, however, traditional integration 
approaches and strategies are unable to cope at reasonable expense. Usually taking 
several years to design and implement, the monolithic approach makes it difficult 
and expensive to change. In fact, frequently changing them takes far longer than 
the life of the proposed alliance. The dynamic, intrinsically heterogeneous 
environment of today and that of the future is posing a major challenge to the 
information and communication technology community. New approaches to 
integration of information systems are vital for today’s manufacturers. 

However, it is the view of many researchers that a clear and cohesive vision of 
how these approaches might relate to the product and process cycles is missing. It 
is clear that information systems must support product life cycles and business 
processes. Furthermore, there is a significant effort in enterprise modeling and 
understanding enterprise transformations. Yet, the connection between ICT and 
enterprise modeling is weak, and research efforts are mostly unconnected. The 
DIISM conferences are dedicated to the theme of finding relationships between 
and among information infi-astructure and enterprise modeling researchers. This 
introduction discusses some expected characteristics of future manufacturing 
enterprises, including some definitions of virtual or extended enterprises, explains 
the concept of an information infrastructure and links it to these characteristics. It 
concludes with some suggestions for further research, which are drawn from the 
discussions at the DIISM 98 conference. 




Characteristics of future manufacturing industries 

Extended or virtual enterprises 

Extended or Virtual enterprises are cooperative arrangements in which 
complementary core competencies from a number of companies form a new, 
temporary alliance to address a market need. Here the terms “Virtual” and 
“Extended” are used interchangeably. A core competency of a company is an area 
in which that company has a major competitive advantage. It can be in design, 
marketing, distribution, specific production processes, or any other business or 
engineering process in a company. It can be as small as a single key production 
process or as large as the Marketing Department. 

Instead of trying to build competency in areas where they are weak, a company 
that has recognized a market demand seeks out partners with competencies, which 
are complimentary. Forming such an organization is difficult since not only must 
the organization have a complete suite of competencies required to service the 
market, but the cultures in the various components must be compatible, the 
business processes must be clearly defined and the sharing of information is 
necessary. Extended or virtual enterprises often include the customer who supplies 
the requirements of the market. Such enterprises must also consider the disposal of 
the product after its useful life. 

The environment for information and communications technologies in such 
enterprises is challenging to say the least. In this environment, not only are the 
data that must be exchanged and shared with partners in different formats and use 
divers data storage mechanisms, but communication protocols, server technologies, 
user interfaces, and control approaches all differ. Legacy applications and data are 
the norm. 

Breadth and depth of the product life cycle 

In the very early stages of industrialization, the artisan had to encompass all 
business and engineering processes. He was the marketeer, the designer, the 
production planner, the accountant, and often the worker on the shop floor. This 
natural integration disappeared with the advent of Taylorism in which work was 
divided into small increments which one person could easily actualize. The recent 
trends illustrated by such concepts as concurrent engineering, and integrated 
product and process design, seek to bring all the disciplines required in the design 
and production of a product back together, particularly during the design and 
development phase. With increasing frequency, designers have to account for the 
disposal of the product at the end of its useful life. Recycling products with new 
features added is increasing. A fiirther trend is that products contain more 
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software, which is becoming a major cost driver. Co-design of hardware and 
software is becoming increasingly more important. 



Digital form of the information required at each stage 

Integration of all the disciplines required to design and produce a high quality 
product can be achieved by non-technical means. However, sharing of paper 
drawings and redoing paperwork is no longer an option if a company is going to be 
first to market. Digitization of product data is a necessity of modem life. There 
are two aspects to this trend: virtual prototyping and electronic collaboration. 
Virtual prototyping occurs when the design team can simulate in a computer both 
the operation of a product in its environment and its total production, before any 
hardware has been created. Virtual prototyping allows companies to dramatically 
accelerate the product design cycle since they can identify a large fraction of 
potential problems from the simulations before the product reaches service. 
Virtual prototyping reaches from simple fitting of geometric models to a finite 
element analyses of the forging process to flying aircraft or driving cars in 
synthetic environments. Electronic collaboration allows the design team to be 
located anywhere in the world, yet simultaneously view models and simulations 
with other team members so that joint decisions can be made almost 
instantaneously. 

Information Infrastructures 

Many current information systems were designed when mainfi'ames were 
predominant. Because of the size of the investment in hardware and software, 
many of these systems are still running major business applications today. 

With the advent of the PC, use of such monolithic systems is declining, but they 
are still a mainstay of many organizations. A major trend was to client/server 
computing, which still involved the main frame as the server, but took advantage 
of the local processing power available in the PC. The current trend is to network 
computing or distributed computing where data and functions are located 
anywhere on a network (e.g. Internet) and available to anyone. 

Information Infrastructures are support systems to enable the creation of 
information systems to meet business needs. One concept described in this book is 
an information infrastructure, which allows various components (data, 
applications, functions, machines, and people) to be dynamically inserted or insert 
themselves to function as a new system. Distributed object oriented frameworks 
are one approach to this concept, but there are others as can be seen by reading this 
book. If they are designed correctly - and no one really knows what that means at 
present - they can become an enabler for extended enterprises, digital prototyping 
and integrated product and process development. 
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Enterprise Models 



A common understanding of the enterprise is critical for any improvement effort. 
Without models, it is difficult to perform any kind of engineering. Therefore, it is 
imperative that any ICT effort fully grasp the implications of any type of change 
including new technologies and infrastructures to support these technologies. 
Enterprise models enable the common understanding of various aspects of the 
enterprise. Emerging modeling methodologies and architectures bring the necessity 
of enterprise models into real world implementations. Models must be considered 
as a tool for: common understanding, decision-making, enterprise control, and the 
actual execution of the business of the enterprise. To use models for only one or 
two of these manners is to minimize the effectiveness of such a resource. 

The models also must be used to describe the enterprise in a holistic manner. If an 
ICT is implemented with only regard to the ’’main” requirements, benefits of the 
new infrastructure may be lost. An enterprise model is by its very definition about 
the entire enterprise and considers all aspects of the enterprise, which includes the 
strategy of the enterprise, the people and the culture of the enterprise, the 
processes, and the technology of the enterprise. 

Future research needs 

One of the more notable conclusions which can be deduced from the papers at this 
conference is the continuing disconnect between enterprise modeling and 
information infrastructures. It was clear from the papers that the two research 
areas still did not refer to papers in the other area. By providing a common forum, 
opportunity for more integration of the two domains should occur. Unfortunately, 
this has not yet occurred. Perhaps the organizers of the next DIISM conference 
could force the issue by asking specifically for papers in which the two domains 
are discussed together. Along a related vein, there is a multitude of approaches to 
information infrastructures themselves. Comparison and identification of the 
advantages and disadvantages of each approach, and the particular environments 
for which they are most appropriate would help researchers and those dedicated to 
implementation of ICT understand which approach is appropriate to their particular 
environment. 

It is apparent that, in the ICT domain, we do not understand the interaction among 
technology advances, business processes, and the culture of the people. One 
approach in the past is that we start by simplifying and redesigning the process for 
automation, then develop an information system to support the new simplified 
process. However, ICT can so radically change processes, that it is frequently not 
possible to design the process before the technology is introduced. We also know 
that some people easily adapt to working with new technology while others resist 
the same technology most strongly. This area for research is also related to the 
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disconnect between ICT and Enterprise Modeling. More research involving 
research in human behavior is required to understand this interaction. 



There is a lack of common standards or too many standards for a variety of areas: 
product design, communications, enterprise models. In product design, STEP is 
slowly emerging as an extremely complex approach to standards for product 
representation. While there are now STEP standards for some aspects of product 
representation, vendors still wish to retain the competitive advantage of their 
particular representation resulting in many unneeded translators. Moreover, the 
representation technology is changing so rapidly that a new methodology may 
emerge before agreement is reached on the current approaches. 

In this book, there is strong emphasis on the object-oriented paradigm to the 
neglect of other possibilities (e.g. functional programming, holons, monads). 
While 00 is a powerful methodology and there appears to be an emerging OO 
modeling standard (e.g. UML), there is evidence emerging that sometimes 
functional approaches are shoehomed into the 00 paradigm without much thought 
on how the project goal could perhaps be better reached. For example, while a 
business can be represented by objects quite well, the flow of information through 
a business process is intrinsically functional. An activity in a process, and actually 
the whole process, transforms an input set of data into an output set. Some recent 
work on Monads as functional programming modules is relevant here. Research 
on the appropriateness of 00 technology in its current form for automating 
business processes would help clarify this issue. 



About this book 



This book brings together a number of leading experts from around the world who 
have worked extensively on these and related topics. Experts from industry, 
consultants and researchers put their views forward on the current levels of 
industrial awareness, standards development, and research and development. 
These proceedings do not offer solutions for all the problems listed before, but it 
gives a fair overview of ongoing efforts and results on which to base further 
cooperative research and development. We hope that this book will be a useful 
source of information for further research and development on information 
infrastructures for manufacturing, and that it may nurture solutions for the open 
problems highlighted during the conference. 

John Mills 
Fumihiko Kimura 

Fort Worth, Texas and Tokyo, Japan, 1998 
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PERA and GERAM—enterprise 
reference architectures in enterprise 
integration 
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Purdue University 

1293 Potter Center, West Lafayette, IN 47907-1293 USA, 
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Hong Li 

Senior Consultant, Claremont Technology Group, Inc. 
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Abstract 

This paper describes PERA (the Purdue Enterprise Reference Architecture) and 
shows its relationships to GERAM (the Generalized Enterprise Reference 
Architecture and Methodology). PERA was developed at Purdue University 
during the period 1989-94. GERAM was developed by the IFAC/IFIP Task Force 
to illustrate that all “complete” enterprise reference architectures should map 
together and have comparable characteristics and capabilities. 

Keywords 

Enterprise integration, reference architecture, computer integrated manufacturing, 
program or project architectures, physical system architectures, PERA (Purdue 
Enterprise Reference Architecture), GERAM (Generalized Enterprise Reference 
Architecture and Methodology). 




1 INTRODUCTION- WHAT IS ENTERPRISE INTEGRATION? 



This paper will initially describe some of the systems engineering aspects of 
enterprise integration and use them to show the development and use of PERA 
(Purdue Enterprise Reference Architecture). We will then show how PERA 
combines with other available enterprise reference architectures (CIMOSA and 
GRAI-GIM) to give GERAM (the Generalized Enterprise Reference Architecture 
and Methodology). It will be seen that PERA contains all of the capabilities of 
GERAM but the latter’s presentation is influenced by the individual characteristics 
of the three architectures mapped within it. 

Enterprise integration can be defined as: —the coordination of the operation of 
all elements of the enterprise working together in order to achieve the optimal 
fulfillment of the mission of that enterprise as defined by enterprise management. 
Note the emphasis on ah and on optimal . All elements means: 

1. All direct mission enabling elements of the enterprise (that is, all of the 
equipment providing the product and/or service functions which comprise the 
mission to the customers of the enterprise), 

2. All control and information function enabling elements (equipment again), 
and 

3. All humans involved in the enterprise (humans may serve along with the 
equipment in either the direct mission enabling functions and/or the control 
and information functions which monitor and control the mission elements). 

Please note that in this context, the word enterprise comprises the whole of how 
a business operates as just described here and not just the business process (or 
management type) functions as indicated by the title - Enterprise/Control 
Integration. Unfortunately, enterprise integration, as used in many of the 
applications being carried out today, discusses only the information and control 
aspects of the overall enterprise which will be described in this paper. 

We should note also here that enterprise integration subsumes unto itself all of 
the “buzz word” techniques being paraded by consulting groups today. Terms 
such as: agile manufacturing, business process reengineering, CIM [computer 

integrated manufacturing], etc., are used. All of these attempt to skim the cream 
from the milk of overall enterprise integration, but all are doomed to failure 
because they are short-cut, incomplete, partial solutions to a much larger problem. 

All of the benefits claimed for those short-cut solutions obviously apply to 
overall enterprise integration itself. It would be repetitious to list them again here 
since they have been broadcast so widely and so often by the practitioners of the 
other proposed solutions. Nevertheless, they must all be considered to apply. 

Let us now discuss some systems engineering concepts which will explain what 
we have just said above and lay out the path to enterprise integration fulfillment. 
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2 THE SIMPLIFYING CONCEPTS OF SYSTEMS ENGINEERING 
IN ENTERPRISE INTEGRATION 

What we will present here are a set of axioms of systems engineering [Williams 
(1961), Checkland (1985), Sage (1992), and Thome (1993)]. Axioms are elements 
of intuitive or logical knowledge which cannot be proven. They can only be 
disproved by a counter-example. The concepts presented here are generic, that is, 
they apply to any and every enterprise, everywhere. It is this genericity which 
makes the practice of enterprise integration engineering possible at all, even with 
computer help. 

2.1 Concept I - The Universality of these Concepts 

While the early work in CIM, and of enterprise integration as well, was largely 
confined to the field of discrete manufacturing, it can readily be shown that the 
basic principles involved apply to any enterprise, regardless of its size and mission 
or any of the other such attributes involved. These are generally principles which 
apply to all aspects of the field of systems engineering. In addition, it is a mistake 
to confine the integration discussions to information and control systems alone. 
Often there are problems within the mission system (manufacturing or other 
customer product and service operations) whose solution would greatly ease the 
overall plant system problem (i.e., it must involve both information and mission). 

2.2 Concept II -- The Mission 

Every enterprise must have a business or mission (the production and distribution 
of a product(s) or service(s)) which satisfies the needs or desires of one or more 
customers, otherwise it must eventually fail. This mission must be established and 
administered by a central authority of the enterprise. 

This is almost self-evident. However, it is very important that the central 
authority (management?) articulate this mission in a succinct, well-understood and 
motivating manner. This statement is commonly called the Mission. Vision, and 
Values of the enterprise. 

Note also that this mission must usually be accomplished in competition with 
other enterprises vying for the same customer markets. Hence the need for the 
optimality in our definition of enterprise integration. 

2.3 Concept III — Separation of Functions 

In terms of their functional analysis there are two and only two basic classes of 
functions in the operation of any enterprise. These are: 

1. Those involved in operating the “processes” which result in producing the 
“product” which fulfills the enterprise’s mission, i.e., the customer product or 
service business in which the enterprise is engaged. In the manufacturing 
plant these would include all material and energy transformation type tasks 
and the movement and storage of the same materials, energy, goods in 
process, and products. 

2. Those involved in the “control” of the mission in an “optimal” manner to 
achieve the necessary economic or other gains which assure the viability or 
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continued successful existence of the enterprise. These comprise the 
collection, storage and use (i.e., transformations) of information concerning 
the business processes in order to control them, i.e., to develop and apply 
necessary changes to the business processes to achieve and maintain their 
required “optimal” operation. Thus it includes all planning, scheduling, 
control, data management, etc., functions. Likewise, these tasks also include 
all those functions normally attributed to management and related operations. 

These two classes of functions interconnect only in (a) operational data collected 
by sensors which obtain signals which are representations of the status of the 
operating variables of the mission enabling equipment and its “products” being 
produced. This data is then transmitted to the information and control tasks; and 
(b) the operational commands transmitted from the information and control system 
to the mission enabling equipment to change its operation toward “optimality” as 
it exists at that moment. 

Figure 1 diagrams the definitions above. Note that the use of italics on several of 
the terms used here indicates that they are defined in the most general manner 
possible in order to cover the extremely wide range of aims, methods and 
conditions covered. 

These concepts form the basis for our further discussion of enterprise integration. 

I 



I 



MISSION 


Operational 
^ Coiiimands 


INFORMATION AND 


ENABLING 


1 
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CONTROL 


EQUIPMENT 
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PERSONNEL 


(AND PERSONNEL) 
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1 ^ 

1 


AND EQUPMENT 





I 

I 

MISSION-INFORMATION AND CONTROL INTERFACE 



Figure 1 The two classes of enterprise functions and their interconnection 

2.4 Concept IV - Networks of Tasks 

1. Normally, information or data will undergo multiple transformations, i.e., 
many separate tasks (where a task defines each transformation) in fulfilling 
the information-handling requirements for an enterprise or CIM system. 
These transformations or tasks are usually successive operations forming sets 
of sequential and parallel networks. 
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2. The same is true of the material and energy transformation tasks for fulfilling 
the physical production or plant operations requirements for the enterprise. 

3. In each case the networks involved can be combined, if desired, to achieve 
one major network of each type (Informational Transformations or Material 
and Energy Transformations, respectively), the totality of which defines the 
functionality of the enterprise or other business entity being considered (i.e., 
the totality of the information network, plus the manufacturing networks, both 
of which can be developed separately but used conjointly). 

4. The two networks interface in those tasks that develop operating variable 
states or status from the manufacturing processes (sensors) and those that 
deliver operational commands to the operational units (actuators and related 
devices). Except for these tasks and their related requirements, which do 
affect the other networks, each network can be developed independently of 
the other. Figure 1 illustrates this concept. 

5. Initial functional analysis or general study of either or both classes of 
functions above can be carried out without knowledge or concern of how they 
will ultimately be implemented in the operating enterprise. 

The last item is vital to the necessary simplification of the overall work involved 
in enterprise integration planning, design and implementation. 

2.5 Concept V -- The Place of the Human 

For many technological, economic, and social reasons, humans are involved in the 
implementation and execution of many business processes of all types in both 
classes above. Others, of course, may possibly be automated or mechanized. 
Thus there must be three classes of implemented tasks or business processes: 

1. Those of the information and control type which can be “automated” by 
computers or other “control” devices. 

2. Those of the mission tasks or business processes which can be automated or 
rather mechanized by the “mission fulfillment” equipment. 

3. Those functions carried out by humans, whether of the control or mission 
fulfillment class. 

There must be a simple way of showing where and how the human fits in the 
enterprise and how the distribution of functions between humans and machines is 
accomplished. 

To reiterate for clarity, there are only two classes of tasks when they are 
considered functionally, but there are three classes of implementations because 
humans may be asked to implement any of the tasks from either functional class. 

Figure 2 explains the definitions involved in Concept III and opens the way for 
our discussion below of how to determine the place of the human in the integrated 
enterprise, indeed of any enterprise anywhere. We start by remembering that in 
ages past all of the tasks of operating an enterprise were carried out by humans. 
Eventually, some of the mission enabling tasks were carried out by mechanization 
employing animal power. Still later, close to the present time, these 
mechanizations were, to a large extent, enabled by mechanical power. It is only in 
very recent times, in historical terms, that, first, mechanical, then, electrical, and 
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finally computer-based devices have been introduced into the fulfillment of the 
information and control tasks of the right-hand side of Figure 2. 

Figure 2 represents only those functions which were mechanized or automated. 
As noted above, many of these functions, on both sides of the diagram, are still 
carried out by humans. Thus Figure 3 expands Figure 2 to show the human- 
implemented tasks as encompassing both types. 

(Mission Fulfillment Tasks) (Information and Control Tasks) 

MISSION ENABLING INFORMATION AND 

EQUIPMENT CONTROL EQUIPMENT 




Figure 2 Definition of automation and mechanization in relation to 
implementation of the tasks of the enterprise 
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- INFORMATION AND 
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Figure 3 Human implemented tasks may be either of the mission fulfillment or of 
the information and control type 

The reader will immediately respond that many human tasks seem to involve 
both types for one apparent task. But, please note that all such tasks can be readily 
broken down into the requisite two. As an example, operating a machine tool 
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involves controlling the cutting tool (control) and handling the work pieces 
(material handling). 

Thus there are a large number of tasks on each side of Figure 1 . Some, of each 
class, can or must be done by humans. Figure 4 outlines one method of making the 
necessary choice between human implementation or automation. (Let us use the 
word automation in the rest of this paper to indicate both automation and 
mechanization as used earlier. This will make our further discussion much less 
awkward.) 

The procedure to be used here works as listed in the following discussion. To 
show the true place of the human in the implementation of the enterprise functions, 
there is a need to assign the appropriate ones of these tasks and functions 
developed on both sides of the diagram of Figure 1 to the human element of the 
system. This can be done by considering the functional tasks as grouped in three 
boxes as shown in Figures 3 and 4. These are separated by defining and placing 
sets of three dashed lines in the graphical architecture representation. This action 
will separate the two earlier functional analysis streams of Figure 1 into three as 
shown in Figure 4 and thus assign the tasks or functions involved to the 
appropriate boxes. The resulting boxes then define the automated information and 
control tasks which become the Information and Control Systems functions and the 
automated manufacturing tasks which become the Manufacturing Equipment 
System or the Customer Product and Service Equipment Systems functions. The 
remainder (non-automated) become the functions carried out by humans as the 
Human and Organizational System. 

The Automatability Line (see Figure 4) shows the absolute extent of pure 
technologies in their capability to actually automate the tasks and functions. It is 
limited by the fact that many tasks and functions require human innovation, and so 
forth, and cannot be automated with presently available technology. 

The Humanizability Line (see Figure 4) shows the maximum extent to which 
humans can be used to actually implement the tasks and functions. It is limited by 
human abilities in speed of response, breadth of comprehension, range of vision, 
physical strength, and so forth. 

Still a third line is presented which can be called the Extent of Automation Line 
(see Figure 4) which shows the actual degree of automation carried out or planned 
in the subject Enterprise Integration system. Therefore, it is the one which actually 
defines the boundary between the Human and Organizational System and the 
Information and Control System on the one hand, and the boundary between the 
Human and Organization System and the Manufacturing Equipment System or 
Mission Enabling System on the other side. 
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Figure 4 Determining the place of the human in the enterprise 

The location of the Extent of Automation Line is influenced by 

a) Economic 

b) Political 

c) Social 

Customs 

— Laws & Directives 
Union Rules 

as well as Technological factors. The establishment of the Extent of Automation 
Line is therefore a management rather than an engineering task. 

The Automatability Line showing the limits of technology in achieving 
automation will always be outside of the Extent of Automation Line with respect 
to the automation actually installed (see Figure 4). That is, not all of the 
technological capacity for automation is ever utilized in any installation for various 
reasons. Thus, the Human and Organizational System is larger (that is, more tasks 
or functions) and the Information System and Manufacturing Equipment System 
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are smaller (less functions) than technological capability alone would allow or 
require. 

2.6 Concept VI - The Life Cycle 

1. All enterprises, of whatever type, follow a “life cycle” from their initial 
concept in the mind of an entrepreneur through a series of stages or phases 
comprising their development, design, construction, operation and 
maintenance, refurbishment or obsolescence, and final disposal. 

2. Not only does this life cycle apply to the enterprise but also to the enterprises’ 
products as well. Thus, carried further, one enterprise can be the product of 
another. For example, a construction enterprise could build a manufacturing 
plant (enterprise) as its product. The manufacturing plant would then 
manufacture (produce) its own product, such as an automobile. The 
automobile also has its own life cycle, which goes through similar steps to 
those discussed here. 

The simplest representation of Concept VI- 1 is the ladder of phases of Figure 5. 
The simple list of Concept VI- 1 has been expanded somewhat at the top since, as 
will be seen, we feel these phases must be so expanded because of their role in 
enterprise engineering planning. It must be immediately stated that no engineering 
effort is ever only once straight through, recycles always occur — enterprise 
engineering in particular is no exception. However, such recycles are left off of 
this and the succeeding diagrams since we do not know beforehand where they will 
occur and also in order to avoid cluttering up our diagrams. 

2.7 Concept VII - Planning and Organization of the Integration Effort 

1. Because of the magnitude and complexity of any enterprise integration 
project, a major engineering and operations planning effort must be 
accomplished prior to any actual integration work. This is commonly called a 
“master plan.” 

First and foremost, management goals, hopes and dreams for the results of the 
project and for further enterprise operation must be included in project 
planning and execution. These are commonly called the Mission, Vision, and 
Values statement of the enterprise and the project. 

All aspects of the enterprise and its operation must be considered in the 
enterprise integration project analysis. 

2. Once the integration of all of the informational and customer product and 
service functions of an enterprise have been properly planned (the Master 
Plan), the actual implementation of such an integration may be broken up into 
a series of coordinated projects, any and all of which are within the financial, 
physical, and economic capabilities of the enterprise, which can be carried out 
as these resources allow as long as the requirements of the Master Plan are 
followed. When these projects are completed, the integration desired will be 
complete. 

3. All tasks should be defined in a modular fashion, along with their required 
interconnections, so they may later be interchanged with other tasks that carry 
out similar functions but in a different manner should this be desirable. 
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4. Again because of the magnitude and complexity of the overall project and the 
unfamiliarity of most engineers with such an effort, a detailed generic 
methodology for such projects is very important. 

5. This methodology (as explained below) can be represented or modeled by an 
enterprise integration reference architecture. 
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Figure 5 The simplest life cycle 

3 THE METHODOLOGY 

As stated in Concept VII, a vital necessity for successful enterprise engineering is a 
simply expressed and easily understood methodology. Complexity we cannot 
diminish. It is present by definition in all massive projects, of which enterprise 
integration is a prime example. But complexity should be handled by the computer 
system which is admirably suited for such a task. 

The steps or phases of the Purdue Methodology for Enterprise Integration follow 
the expanded set listed in Figure 5. These combined with the seven concepts listed 
earlier result in the Methodology which is outlined in Table I and Figures 6 and 7. 
It will be noted by the reader that the diagram of Figures 6 and 7 is called an 
Architecture as are some of its subdivisions. As stated above, they are a graphical 
model of the methodology. However, a better title was desired since there can be a 
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multitude of models developed in the many processes involved in the work 
indicated in this diagram. 



Table I Phases of the Enterprise Integration Project and of the Subject Enterprise 
Entity — the Enterprise Entity Life Cycle 



Phase 


Title 


Brief Description 


1 


Identification of the 
Enterprise Business Entity 


Establishment of Identity and 
Boundaries of the Enterprise Entity 
Being Considered 


2 


Concept of the Project 


Mission, Vision and Values of the 
Enterprise Entity, Operational Policies 
to be Followed 


3 


Definition of the Project 


Identity Requirements, Tasks and 
Modules and Develop Flow Diagram 
or other Models of the Enterprise 
Entity 


4 


Specification or Preliminary 
Design of the Project 


Identify Human Tasks, Initial Choice 
and Specification of Human 
Organization and of Information and 
Control Equipment and Mission 
Fulfillment Equipment 




Note (1) The Master Plan Involves All of the Above Information 


5 


Detailed Design of Human 
and Organizational, 
Information and Control, and 
Customer Product and 
Service Components of the 
Enterprise 


Completion of All Design in Detail 
Needed for Construction Phase 


Note (2) Phases 4 and 5 are Often Combined as One Design Phase. However, 
the Differences in Effort level and the Need for Master Plan Completion at the 
End of Phase 4 Indicates Their Desirable Separation Into Two Phases 


6 


Implementation or 
Construction, Test and 
Commissioning Phase 


Conversion of Detailed Design to 
Actual Plant Elements, Their Testing, 
Operational Trials and Acceptance or 
Commissioning 


7 


Operations Phase 


The Period of Time While the 
Enterprise Entity is Carrying Out Its 
Mission as Prescribed by Management 


8 


Decommissioning 


The Enterprise Entity Has Come to the 
End of Its Economic Life, Must be 
Renovated or Dismantled 
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Figure 6 Development of Purdue methodology and the Purdue Enterprise 
Reference Architecture 



Since the diagram represents the structure of the project of planning, designing, 
implementing and operating an enterprise, it was decided to call it an architecture. 
An architecture is, of course, a description (often graphical) of the structure of 
something. Since the later applications are usually of a physical entity rather than 
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a project, it was decided to call the project conduct structure a Type II architecture 
in contrast to the physical example (Type I). 
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Figure 7 Continued development of the Purdue methodology and the Purdue 
Enterprise Reference Architecture 

Likewise, the parts of the diagram which described the development of the 
Customer Product and Services System and the Information and Control System 
became subarchitectures of the overall diagram. The complete architecture, as 
developed, was labeled the Purdue Enterprise Reference Architecture [Williams 
(1994)] because of its genericity and overall applicability. 

The methodology can be described as follows: 
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The Methodology of Enterprise Integration presents a set of instructions 
(text, computer programs and tools, models, graphical diagrams, etc.) 
which gives a step-by-step aid to the user in carrying out all needed 
aspects of the execution of the life cycle phases or steps of the enterprise 
entity integration project. In this way it describes the processes of 
enterprise engineering and integration. 

As noted earlier, the first task of the methodology is to assure that the Master 
Plan to be developed by the enterprise integration-planning team is complete, 
accurate and properly oriented to future business developments. As Table I 
describes, the Master Plan summarizes all the information developed in the first 
four phases of the life cycle and presents these for management approval along 
with the division of the overall projects into a manageable set of smaller, 
subprojects. 

There are two reasons for the selection of this location to define the Master Plan 
[Williams (1994), Williams, et al. (1996)]. This represents the maximum of 
information available from the relatively small planning team, thus the most 
information for the minimum costs. Likewise, the next phase, detailed design, will 
involve a major increase in manpower and costs for the project. Thus this point 
becomes the last chance decision point which management has to review the 
project before major costs are expended. 

The methodology must also provide a number of checklists to assure that the 
Master Plan developed by a company integration-planning team is complete, 
accurate, properly oriented to future business developments, and carried out with 
the minimum of resources, personnel and capital. This needed methodology would 
thus: 

1. Describe the tasks to develop the Master Plan including its continual renewal. 

2. Define the necessary quantity of information and data. 

3. Specify the informational, the human-organizational, and the customer 
products and services interrelationships in the integration considered. 

4. Consider and address management concerns. 

5. Present relevant economic, cultural, and technological factors. 

6. Detail the extent of computer support required. 

7. Detail estimated costs, benefits and timing of the proposed integration project. 
Once the Master Plan has been prepared, submitted to management and the 

continuation of the project approved, the methodology will continue to provide 
guidance and advice on the conduct of all the succeeding phases. Previous work 
has shown that the conduct of the enterprise integration project and thus this 
methodology can be generically prepared to a very high degree [Bernus, et al. 
(1996)]. Of course, the fine details of any project will vary from each other but, as 
noted, the overall details are amazingly generic [Rath well and Williams (1996)]. 

Figures 6 and 7 provide a diagram which is effectively a model of the 
methodology described here. The methodology and this diagram are derived from 
the concepts presented here. Note the following: 

1. The Concept Phase (an unfortunate second different use of this word) 
develops the details of the Enterprise Mission of Concept II. Figure 8 shows 
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the place of Upper and Middle Management (Steering Committee) in 
preparing this part of the Master Plan. This material is presented to the 
succeeding investigations in the form of the policies needed to carry out the 
mission of the enterprise. 
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Figure 8 Who carries out the tasks involved 



2. The major work of developing the Master Plan is carried out by a Planning 
Team whose members are expert in the technology involved but also made up 
of members of the future operation staff of the enterprise to the highest extent 
possible. From the Policy and Mission Statements they use the lead of 
Concepts III to VI to evaluate the proposed project and prepare the Master 
Plan itself. The Definition Layer (Figure 6) shows the steps involved in 
modeling the networks for both the Information and Control and the Customer 
Product and Service Systems. The Functional Design or Specification Layer 
follows the structure of Figure 4 to show how the tasks of the enterprise are 
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assigned and the resulting specification prepared. The actual implementation 
systems designs must be carried far enough forward by the Planning Team to 
permit a detailed enough cost estimate for a management decision on whether 
or not to continue with the proposed enterprise integration engineering project. 

3. The Master Plan needs to be in two parts: (a) a management version briefly 
presenting the project’s goals, benefits and costs along with the collection of 
subprojects which can be carried out with the resources of the enterprise at 
hand as noted in Concept VIT2; and (b) a much more detailed version which 
presents all the information necessary for the Detailed Design Staff personnel 
to begin the detailed design work noted in the next phase. This is shown in 
Figure 9. 
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Figure 9 The place of the Master Plan in the PERA structure 

4. There are many computer-based design suites, previous successful design 
examples in computer-readable form, databases of design requirement 
specifications which conform to local and national laws, etc., which are 
available for continuation of the project. These are often collected together in 
the form of Computerized Work Benches for the convenience of design and 
construction staffs. Some example aids available are indicated in Figure 10 in 



18 



both formal and informal programs and documents. Figure 7 indicates the 
tasks to be performed in each area of the diagram as the work progresses. 
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Figure 10 Types of models and tools involved at each phase of the life cycle 

4 SOURCE AND STATUS OF THIS TECHNOLOGY 

The techniques described up to this point in this paper were developed as an 
activity of the Purdue Laboratory for Applied Industrial Control (PLAIC) at 
Purdue University, West Lafayette, Indiana. The work was carried out with the 
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support and direct cooperation of a group of 12 industrial companies during the 
period of 1989-1994. This material has been widely published in Purdue reports 
[Williams et al. (1996)], books [Bernus et al. (1996), Williams (1994)] and 
technical papers [Rath well and Williams (1996)], among many others. It has 
already been successfully used by industrial companies for very large projects in 
several industries. 

This said, we must quickly add that the application of this technology (the 
methodology and its associated architecture) would profit greatly and expand its 
use from the following aids: 

1. Widely available instructional manuals in print and on the world- wide web. 

2. More compatibility and interoperabilty of the several design packages, 
communications technologies, and related computer system components 
needed to develop the work benches for applying this technology. Widely 
accepted standards (from whatever source) are vital here. 

3. Much more compatibility in the nomenclature used for the many disciplines 
which interact in projects of the size and breadth of an enterprise integration 
system. It is always amazing to see the wide diversity of use and meaning of 
the same words and phrases across the several disciplines and the resulting 
misunderstandings that result. 

5 INTRODUCTION AND DEVELOPMENT OF THE CONCEPTS OF 
GERAM 

5.1 Origin of the Task Force 

The IFAC/IFIP Task Force on Architectures for Enterprise Integration was formed 
by IFAC (The International Federation of Automatic Control) and IFIP (The 
International Federation for Information Processing) in August 1990. It was the 
first and is, so far, the only such joint operational group established by the two 
different international scientific or engineering federations. The Task Force was 
charged to review the field of its title and report its results to the next subsequent 
IFAC Congress, which was to be held in Sydney, Australia in July 1993. 

The Task Force was formed as a group of manufacturing engineers, computer 
scientists and information technology managers to study, compare and evaluate the 
different available architectures for enterprise integration which were in the open 
literature. The basic task assigned the Task Force was to study those architectures 
and make recommendations for the future development of this field. 

5.2 What is GERAM 

The Task Force early recognized that a single, universally accepted architecture, 
framework, or model would be a major contribution to the field of enterprise 
integration. The group first tried the path of finding an acceptable candidate from 
among those currently available and then extending it as necessary for their 
purposes. 

Failing in this for political rather than technical reasons, the group next resolved 
that a new architecture should be developed from the best characteristics of the set 
of existing architectures being studied by the Task Force. It was further decided 
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that these same political rather than technological factors again dictated that this 
new architecture should be developed only as far as the specification stage. The 
resulting architecture would then become a goal for further development of the 
existing architectures to give those who succeeded the necessary capabilities to 
fully serve the field. The specification would also include the necessary 
application information or methodology. 

The new architectural specification would become GERAM . the Generalized 
Enterprise Reference Architecture and Methodology. 

5.3 The Situation Facing the Task Force 

The following observations were developed by the Task Force members as 
characterizing the Enterprise Reference Modeling Field at that time (September 
1991): 

1. There are a very large number of architectures or models already in the 
literature or developed as proprietary projects by many industrial groups. 

2. None of these were complete as yet. 

3. Most present many of the same concepts but by means of different graphical 
and mathematical methods. 

4. The ancient parable of the group of blind Indian philosophers who attempted 
to describe an elephant after each had felt only different separate parts, 
certainly applies here - Each of the proposed architectures is describing the 
same subject but from widely varied, and very incomplete viewpoints. Thus, 
the descriptions appear to be very different. 

5. The work of the Task Force was to sort all of this out - as noted above. Their 
first task was to make a comparative analysis of the available models. They 
would then attempt to distill the needs of the field from these existing 
proposals. 

6. The best solution would be to be able to adopt one existing model or 
architecture as best - failing this, build on an existing system by supplying the 
apparently missing capabilities - the last resort would be to specify a whole 
new one from the characteristics of several of the others. 

5.4 Early Work of the Task Force 

The early work of the Task Force quickly showed: 

1. There are two basic types of enterprise integration architectures available 
today: (1) those which describe the architecture or physical structure of some 
component or part of the integrated system such as the computer system or the 
communications system and (2) those which present an architecture or 
structure of the project which develops the integration, i.e., those that illustrate 
the life cycle of the project developing the integrated enterprise. This was 
discussed earlier in the PERA presentation. 

2. The experience of many CIM program groups world-wide has shown the 
value of a reference architecture of the second type above in guiding the 
separate stages of planning, establishment, analysis, specification, detailed 
design, construction and commissioning, and operation of projects for the 
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integration of information and manufacturing activities in industrial plants and 
indeed all types of enterprises everywhere. 

3. Thus, the most valuable architectures are those which model or describe the 
structure of the integration programs themselves, i.e., the developmental and 
application stages in the life history of the program. These were labeled as 
Type 2 architectures. 

4. These Type 2 architectures will include as vital component parts many 
examples of the other major type of reference architectures. These latter 
architectures, to be known as Type 1, model or describe the structure of the 
computer system and/or of other major components which comprise the 
overall integration system as finally developed. The vast majority of the so- 
called reference architectures in the literature today are of this second type. 

5. The Task Force also determined that it is vital that the Type 2 reference 
architecture be accompanied by a methodology which gives detailed 
instructions to user project development groups on how to use the architecture 
to guide the conduct and progress of their study. The methodology should 
also detail the nature and use of all available techniques and tools valuable to 
the user group at each stage of the development and operation of the 
integration program and/or project. 

6. Enterprise integration is a very complex and highly detailed endeavor. 
Similarly, the reference architectures which describe this endeavor are also 
complex and highly detailed. As a result, none of the candidate architectures 
and associated methodologies were, at that time, completely developed, 
described and documented. However, in each case the path to their ultimate 
completion was clear either from the work of the architectural development 
group themselves and their future plans or from the associated work of other 
groups, including the Task Force. 

7. Each of the studied architectures and their associated methodologies should be 
extended by the original development groups or others to become a complete 
architecture and methodology for guiding enterprise integrating programs 
from initial conception to their construction and use. 

8. It would also be possible, and perhaps more rewarding, to combine the best 
parts of each of the candidate architectures to capture the possible synergy in a 
new or combined architecture. 

9. The more common type of architecture in the literature today, as noted in Item 
4 above, is that of Type 1 above which shows the structure of the integrating 
computer system, for example. These readily become one of the tools or 
techniques listed in Item 5 above, but are only part of the larger overall 
architecture of the development program which produces the desired 
integrated enterprise. 

5.5 The Studied Architectures and the Task Force’s Recommendations of 

Each 

In its work, the Task Force concluded that there were only three Architectures of 

the Type 2 variety in the open literature which were developed far enough to be 

valuable for study by the Task Force. These three architectures were: 
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1. CIMOSA - As developed by the AMICE Consortium under the ESPRIT 
Program of the European Community [see (Bernus et al. (1996)]. 

2. GRAI-GIM - As developed by the GRAI Laboratory of the University of 
Bordeaux, Bordeaux, France, under its own research program for production 
management systems and with the aid of ESPRIT [see Bernus et al. (1996)]. 

3. PERA — The Purdue Enterprise Reference Architecture and its associated 
Purdue Methodology - As described in the earlier part of this paper. 

CIMOSA can be characterized by its “cube” model as shown in Figure 11. 
GRAI-GIM is shown in Figure 12. 



THE DEGREE OF GENERICITY 
STEPWISE INSTANTIATION ^ 




Figure 11 The CIMOSA architectural framework - the CIMOSA cube 

Note that the Identification and Concept Layers are missing from CIMOSA since 
they assume this data is already available. Likewise the Manifestation and 
Operation Layers shown in PERA are missing since again CIMOSA assumes this 
is handled by others. 

CIMOSA is particularly noted for its espousal of three separate life cycles in 
parallel, labeled Generic, Partial, and Particular. Generic represents those 
enterprise integration factors generic to all enterprises. Partial are those generic to 
a particular industry, and the Particular represents the enterprise in question. 
CIMOSA recommends proceeding from Generic through to Particular to take 
advantage of existing knowledge in developing a Particular system. Note also the 
Views dimension which permits a reduction in modeling complexity but 
considering only certain aspects of the system in any one model. 
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Figure 12 The GRAI-GIM life cycle diagram 

GRAI-GIM considers the Identification and Concept Layers as important for the 
enterprise integration study but does not include a Build and Operations regime 
since their aim is only to prepare the design for the new system. 

Space does not permit a further critical description of the CIMOSA and GRAI- 
GIM enterprise reference architectures in this paper. Interested readers are urged 
to consult some of the references in the bibliography of this paper. The above- 
listed figures should be compared to the corresponding PERA figures presented 
earlier to show the tremendous differences in presentation forms facing the Task 
Force in its early work. 
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5.6 The Origin of GERAM 

Dr. Francois Vernadat, a Task Force member, organized a Special Session on 
Enterprise Modeling and Integration for the ICARCV’94 Conference to be held in 
Singapore in November 1994. This Special Session formed a major opportunity to 
kick-off the development of the consolidated architecture recommended earlier by 
the Task Force . 

It was further agreed that a title was needed for this new architecture, and that of 
Generalized Enterprise Reference Architecture and Methodology (GERAM) was 
selected as a highly suitable one. The Special Session would then be a collection 
of papers prepared by Task Force members outlining the requirements for GERAM 
and the contributions which each of the candidate architectures could make 
towards it. 

As the only active members of the Task Force who were not already deeply 
involved in developing and promoting their own Enterprise Reference 
Architecture, Dr. Peter Bernus and Dr. Laszlo Nemes were requested to prepare a 
paper giving an initial specification and discussion of GERAM. 

This paper pointed out several aspects of Enterprise Reference Architectures 
which had not previously been widely discussed by the Task Force members in 
their meetings and correspondence. These were: 

1. The expansion of the coverage of the Architecture to cover a much wider 
range of applications: 

(a) Products; 

(b) Enterprises Producing These Products; 

(c) Enterprise Integration Companies Carrying out the Development of 
Enterprise (b) above; and 

(d) Strategic Enterprise Management. 

This expanded coverage was described by Bernus and Nemes as the “recursivity” 
of GERAM [Bernus and Nemes (1996)]. 

2. Definition of Six Different Components of the Generic Enterprise Reference 
Architecture and Methodology: 

(a) The Generic Enterprise Reference Architecture itself (GERA); 

(b) The Generic Enterprise Engineering Integration Methodology (GEEM); 

(c) Generic Enterprise Modeling Tools and Languages (GEMT and L); 

(d) Generic Enterprise Models (GEM); 

(e) Generic Enterprise Modules (GM); and 

(f) Generic Ontological Theories (GT). 

They also proposed a so-called “matrix model” of GERAM. This latter was a 
slight modification of the generic mapping tool of the Task Force’s 1993 Triennial 
Report [Bernus et al. (1996)] which by definition serves this purpose since it had 
been the basis for mapping the characteristics of all studied architectures in the 
Task Force’s previous work. 

The "matrix" model for GERAM (Figure 13) was developed by combining the 
distinctive characteristics of each of three studied architectures into one diagram. 
It is easy to recognize the three classes of genericity from CIMOSA 
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Figure 13 Original Task Force architecture design diagram, the "matrix" model 

(Generic, Partial, and Particular); the life cycle of PERA (somewhat modified to 
recognize the different titles used by CIMOSA); and the views of GRAI-GIM and 
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CIMOSA along the bottom. Thus it was possible to map the capabilities of each 
on these diagrams and make a graphical comparison of them. 

However, when one wished to discuss GERAM itself, this diagram became too 
complicated (note that the Human-Machine separation of PERA is now horizontal 
and does not follow the Life Cycle). 

It was possible to manipulate this diagram to develop a companion three- 
dimensional figure (Figure 14) which was much more expressive of GERAM and 
its derivation. Here the reader can see that the CIMOSA cube is now in its original 
form (Figure 11) as is GRAI-GIM in the right-hand column of Figure 14. 

PERA becomes the front face of the three-dimensional block figure as shown in 
Figure 15. This is because PERA does not require the view structure proposed by 
CIMOSA and retained in GERAM. It can, of course, be used if desired but is not 
considered necessary. PERA appears in all three rows of life cycles. 

6 RECENT WORK 

A major part of the recent activities of the Task Force have been involved with the 
International Standards Organization (ISO) to standardize the requirements for a 
’’complete" generalized enterprise reference architecture and methodology - not 
GERAM specifically but all enterprise reference architectures and methodologies 
which aspire to use the completeness title. In this work the Task Force is 
cooperating with ISO/TC184/SC5AVG1, entitled Modeling and Architecture. The 
proposed standard is near Committee Draft form (now ISOAVD 15704) and is 
expected to be released for initial consideration and initial balloting in the near 
future. It is formally entitled. Requirements for Enterprise Reference Architecture 
and Methodologies. 

1 SUMMARY 

PERA, as described in this paper, along with its associated methodology for 
application, is enjoying widespread use in industry for application to all types of 
industries. It is also being widely studied in educational institutions around the 
world. It seems to be providing the necessary guidance for enterprise engineering 
integration projects which had been missing up to this time. We look forward to 
ever increasing use. 

GERAM provides the same capabilities as PERA through its inheritance from 
the use of PERA in developing GERAM. It uses a somewhat more complicated 
graphical representation, however, through the desire of the Task Force members 
to be able to readily map all the other architectures studied by the Task Force into 
this one structure. 



27 





Figure 14 Representation of CIMOSA "cube” and the GRAI-GIM structured 
approach (far right column) on the reconstructed matrix 
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Figure 15 Representation of PERA on the reconfigured matrix 
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Good afternoon. Thanks for inviting me to speak today. It’s a pleasure to be here 
w'ith this group of internationally respected scientists and engineers. I recognize 
some of you from my involvement in the Intelligent Manufacturing Systems 
Program. 

In a sense, we are here to exchange perspectives on what is essentially the “One 
Trillion Dollar Question:” why isn’t the world, in general, and the manufacturing 
sector, in particular, realizing the full range of benefits that the $1 trillion global 
investment in information technology should buy? 

Clearly, companies and consumers are benefiting to some degree. Why else would 
spending for information technology be increasing at an annual rate of 12 percent? 
At this rate, the world’s information technology bill will double to $2 trillion in 
less than seven years. That’s a lot of money to spend on technology that still has a 
long way to go before it approaches its full potential. 

So, we’re meeting here in Texas to discuss how one sector of the world’s 
economy — manufacturing, an extremely important sector and a major creator of 
wealth — can make the most of its investments in information technology. And the 
title of this conference — Design of Information Infrastructure Systems for 
Manufacturing — places the emphasis right where it should be: on infrastructure. 




Today, you can invest in the world’s most advanced equipment to run the world’s 
most advanced software applications, and you’ll still end up with heartburn and 
lots of disappointment. Executives and managers of manufacturing operations still 
will complain: 

• That the information they need is not what they have. 

• That the information they have is not what they really need. 

• And that the information essential to solving a problem is not available, at 
least not in a form that supports good, timely decisions. 

Now look ahead to the extended enterprises of the future that we all like to talk 
about. Visions of 2T‘ century manufacturing anticipate seamlessly integrated 
collections of geographically separated suppliers and customers whose operations 
are synchronized like the movements of ballet dancers. Yes, I’m being facetious, 
but there is no shortage of hyperbole when talking about future manufacturing 
enterprises — about next-generation manufacturing. 

So, let’s get back to current day reality. Think about the difficulty of integrating 
information systems within companies, let alone across companies that span the 
globe. The current reality is that data often are more like confetti than strategic 
resources. Data structures are incompatible and information systems are 
unconnected. 

Reality, dream. . . . Benchmark, aspiration. . . . What is, and what can be. 

My point is simply this: We must think big. We must be ambitious in our long- 
term goals. We must aim for perfect functionality - and plug-and-play 
compatibility - and all the other - ‘ilities,” such as interoperability, extensibility, 
scalability, portability, reconfigurability, and so on. 

But we also must sweat the details. And in this arena, many of the key details take 
the form of standards. Standards are the brick and mortar of the information 
technology infrastructure that the manufacturing sector so clearly needs. 
Unfortunately, standards are lacking or are immature in many key areas. And 
sometimes the standards are so complicated, so broad in scope, that they take a 
decade to develop, a situation that won’t work in the information age. 

So a major challenge that we all face is making the standards system — and the 
standardization process — more responsive, more relevant, more in- step with 
technology trends and industry needs. If we don’t, then decades from now, we 
may be repeating the prediction that futurist John Diebold made back in 1952. In 
his book Automation, Diebold wrote: 
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“[T]he elements of the automatic factory are already with us; all that 
remains is to connect the proper instruments to the computer and attach 
our machines.” 

Professor David Dilts of the University of Waterloo in Canada quoted this passage 
in a presentation that he recently gave at NIST (National Institute of Standards and 
Technology). I found it to be instructive as well as cautionary - and worth 
repeating. 

Part of the reason for the divide between vision and reality is simply that the 
technology isn’t there yet — although, clearly, lots of progress has been made, 
especially within the last few years. Another part of the reason, I submit, is the 
gulf-maybe, wall is a better word — that stands between planning for 
manufacturing information systems and the other strategic and operational 
elements of manufacturing. 

I think that we have reached — or, at least, are approaching — an advantageous point 
in the evolution of science and technology and in the evolution of manufacturing 
organizations. This is a point at which information technology will be organic to 
all facets of manufacturing. Several complementary trends, I believe, are 
converging on a threshold that will result in the full flowering of information 
technology in manufacturing. 

About NIST 

Before I elaborate, I should provide you with some context— some background 
information on my organization, the National Institute of Standards and 
Technology. With this information, you should be able to judge how many grains 
of salt you might need to swallow with what I’ll be saying about future directions 
in manufacturing technology and its applications. 

NIST is part of the Commerce Department. We work with industry to develop and 
apply technology, measurements, and standards. That’s our mission. And we 
carry it out through four major programs: 

One is the Advanced Technology Program (ATP). The ATP is a competitive, cost- 
shared awards program for U.S. industry. It fosters and accelerates early-stage 
development of high-risk technologies— many of them with the potential 
significantly to improve manufacturing processes and capabilities on industry-wide 
scales. The chart contains a list of major project areas with a heavy manufacturing 
concentration. 

Then, there’s the Manufacturing Extension Partnership (MEP). This cooperative 
program is a nationwide network of technical assistance centers set up to help 
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smaller manufacturers modernize their operations. One key thrust is to help these 
businesses develop the capabilities needed to become agile, high-performing 
suppliers that prosper in this dawning era of supply-chain-centered competition. 
MEP has 78 centers located throughout the U.S. with 300 field offices out of this 
network, and out of which more than 2000 field engineers operate. 

The National Quality Program, the third element of NIST’s portfolio, manages- 
with industry-\hQ Malcolm Baldrige National Quality Award. Many people 
believe that the Baldrige Award is among our nation’s best examples of effective 
cooperation between government and industry. 

Finally, there’s the NIST program of laboratory research and services, a job we’ve 
been doing for nearly 100 years. Our seven laboratories attend to the care, feeding, 
and development of the U.S. technology infrastructure. 

This includes: 

• measurement methods, 

• calibration services, 

• quality assurance capabilities, 

• generic industrial technologies, 

• software interface standards, 

• accredited testing laboratories, and 

• evaluated scientific data. 

In important— but often invisible— ways, these products and services support your 
companies’ performance in the laboratory, design shop, factory, and marketplace. 
And they’re becoming increasingly crucial to trade. 

In fact, the framers of the U.S. Constitution understood that, for efficient 
commerce, we need a trusted system of money and a trusted system to measure 
quantity and performance. Without these essential supporting elements, an 
economy can’t move beyond the barter system. 

For example, when we buy gasoline, we expect the volume of a gallon or liter to 
be the same at all stations. If we’re willing to pay a premium price for higher 
octane, we assume there exits a measurement system that assures we get what we 
pay for. Or, if we're buying a new computer and are considering paying a higher 
price for a 330-MHZ processor rather than a 233-MHz processor, we assume there 
is a measurement system that can tell the difference. 

The U.S. Constitution assigns responsibility for the nation's monetary and 
metrology systems to the Federal government, and these roles are carried out in 
similar ways. Banking is a private sector enterprise enabled by the Federal 
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government. Functioning as a central bank, the government supplies currency, 
assures that the domestic system operates fairly, and fosters international 
acceptance of U.S. currency. In the same way, metrology is a private sector 
enterprise with the Federal government providing a central metrology function. 
The Federal government also assures that the domestic system operates fairly, and 
fosters international acceptance of U.S. measurements. 

Through NIST, the Federal Government also expands and strengthens the 
measurement system as technology advances. And we all know that advancing 
technology is vital for commerce and international trade. It accounts for 
approximately 50% of U.S. economic growth. It drives demand for new 
measurements and standards. And it requires that NIST maintains state-of-the-art 
scientific facilities. 

Consumer confidence in the marketplace depends on the measurement chain and 
the quality of our support of the fundamental units and the measurement 
infrastructure, and the leverage here is impressive. The annual investment in NIST 
is about $400M, less than .5% of all Federal R&D (research and development). 
This undergirds $10 B per year in private sector investment in measurement and 
standards. And it impacts the U.S. economy in an astounding way: more than half 
of $7.6 trillion per year U.S. GDP (Gross Domestic Product) is supported by 
measurement. 

As an aside for those of you interested - all standards are derived from a few 
fundamental units. So, for example, acceleration is derived from length & time, 
work is derived from length and force, and force is derived from mass & 
acceleration. Also, each unit has an internationally agreed upon method for 
realizing and disseminating it through the measurement transfer chain, from basic 
units to those derived for everyday applications. 

Overview of Trends 

My job as director of the NIST Manufacturing Engineering Lab-a 400-person 
R&D and service operation— is the vantage point from which Fd like now to talk 
about several prospects for the future of manufacturing engineering. 

ril go out on a limb and talk about how collaboration can transform these trends 
into advanced manufacturing capabilities. But before I do, Fd like to show you 
this collection of remarks by people who have misread technology’s tea leaves. It’s 
been posted on scores of Web pages, so you may have seen it in one form or 
another. But the corollary to these off- target projections is a statement by the 
novelist John Galsworthy. He once reminded that, "If you don't think about the 
future, you can't have one.” I can assure you that we at NIST are thinking about 
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the future of manufacturing. And information technology plays a huge role in that 
future. 

The first trend is the trend toward “science based” manufacturing and, especially 
mathematics-based manufacturing. In all facets of manufacturing and at every link 
in the value chain, trial and error is an increasingly costly way of doing business. 
Algorithms, process models, analytical methods, and the like have become critical 
enablers of superior machine tools, more efficient processes, advanced 
manufacturing capabilities, and better decision-making. 

The second path is “integration.” It’s not the installation, but rather the integration 
of technology— and of technology and people— that delivers the decisive 
advantages and improvement gains that manufacturers seek in their capital 
investments. Yet, the dynamic nature of technological change makes integration 
an especially challenging task. 

The third path is “information technology.” Modern information technology is a 
dynamic force. It’s creating an expanding bubble of capabilities and business 
opportunities that we’ve just begun to realize. It’s catalyzing and enabling 
changes in the way companies organize, operate, collaborate, and compete. 
Today’s notions of supply-chain management and virtual corporations are 
examples. Holonics and fractal manufacturing are two others. 

Clearly, all three of these trends are related. Information technology, however, is 
the chief enabler and the chief source of competitive advantage. It is the 
technology that industries and companies — alone and together — will have to 
master, adapt, refine, and exploit. 

Science-Based Manufacturing 

My laboratory and all of NIST devote time, energy, and resources to anticipating 
the future needs of U.S. manufacturers. We have to. 

Consider, for example, that over the last half century, dimensional tolerances have 
been shrinking tenfold every decade or so. State-of-the-art, high-precision 
products of the early 1980s are “off-the-shelf’ today. For the laboratory charged 
with, among other things, maintaining the national standard of length— that’s my 
lab, the NIST Manufacturing Engineering Lab— this progression is a real 
challenge. Our measurement capabilities must exceed industry’s best— ideally by a 
factor of four. 

The microelectronics industry is at the forefront of this relentless push. Ever- 
smaller devices squeezed onto ever-faster and ever-more powerful chips, means 
that we at NIST must forever be splitting hairs— and splitting and splitting them. 
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We’re now at the point where we’re developing measurement tools that are built 
molecule by molecule, and even atom by atom. We’re also developing tools for 
making electrical measurements that count individual electrons. 

Another way to look at this trend is with fire hoses. This slide shows two types of 
fire hoses and their connectors. One is a conventional fire hose; the other is an 
“information fire hose,” an optical fiber, the conduit for voice communications and 
for sending huge amounts of data. 

Shortly after NIST was founded as the National Bureau of Standards, a fire 
ravaged a 70-block area in the City of Baltimore. Engine companies came from as 
far away as New York to help. But most of these volunteers could only stand and 
watch because the threads on their hoses did not match the hydrants and other 
equipment at the scene. 

In fact, the Bureau later determined that, at the time, there were more than 600 
variations in fire-hose couplings. With the Fire Protection Association and another 
organization, NIST worked to develop specifications for a standard coupling. 

In the optical fiber industry, a good connection also is critical. On the slide is a 
carefully manufactured fiber whose diameter has been measured, using this NIST- 
developed measurement reference. This reference is set to an unprecedented level 
of accuracy— about 35 nm, or nearly one three-thousandth of the width of a human 
hair. This “SRM” (standard reference material) makes it possible to use self- 
aligning ferrules like the one shown here to link the wispy strands of optical fiber. 
It helps insure against a poor fit, that would impede signal transmission and, 
ultimately, upset customers. This reference material is a symbol of where much of 
industry is headed. 

In all areas of advanced manufacturing— in discrete parts and continuous 
processing— there's an unquenchable thirst for higher levels of accuracy, precision, 
selectivity, and specificity. Consider, for example, that the longevity and reliability 
of car engines depend on manufacturing tolerances of micrometers— about the 
width of a single bacterium. The push for higher precision and greater accuracy is 
unrelenting. Why is that? Because improvements in these areas translate into 
higher quality, lower costs, less waste, better product performance, and happier 
customers. 

Regardless of the industry, the competitive advantage goes to companies that can 
reliably manufacture and assemble parts and products to ever more exacting 
tolerances. The trend toward greater levels of precision and accuracy has several 
facets. One is the growing complexity of part geometry, which makes it doubly 
difficult to manufacture to tight tolerances. 
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But complex shapes also offer advantages—special features that appeal to 
customers, higher levels of performance, or a single part that can do a job that was 
previously performed by combinations of two, three, or more different parts. The 
aerospace industry with its growing use of high-speed machine tools is a case in 
point. Companies are now machining large thin-walled parts that replace much 
heavier, riveted assemblies made up of many parts. Still, there’s much to be 
learned before spindle speeds can be increased to 100,000 rpm or even higher. 

At NIST’s High-Speed Machining Testbed, we’re working with Boeing in St. 
Louis and Penn State to understand the dynamics of high-speed machining 
processes— with the aim of reducing them to mathematics, as opposed to trial-and- 
error experimentation. 

I can report a couple of recent accomplishments in the high-speed machining area. 
With Boeing, our researchers have demonstrated the concept of tool tuning in 
high-speed milling. By explaining the dynamics of “regenerative chatter”-which 
occurs when a tool cuts over a surface that already has been cut— we have 
developed methods to stabilize the tool at a specified set of operating parameters. 
This has allowed us to take advantage of the full range of speeds that these 
machines offer. 

Progress also has been made in the area of high-speed spindles, thanks in large part 
to funding from NIST’s Advanced Technology Program. Matching funds from the 
ATP enabled the National Center for Manufacturing Sciences (NCMS) to mount 
what NCMS believes to be the first substantial spindle research program. The nine- 
company collaboration has yielded promising prototypes of spindles that are fast, 
flexible, and compact. Two — HydroSpindle and TurboToof-have won R&D 100 
awards. They’re based on the same underlying technology. HydroSpindle 
maintains cutting accuracy up to speeds of 60,000 rpm, and it’s nearing 
commercialization. The other spindle, TurboTool, has farther to go, but Aesop, the 
company that developed the technology is aiming for speeds of 100,000 rpm with 
continuous power of 100 kw. 

At NIST, a number of projects-past, present, and future-have been designed with 
the aim of improving machine tool capabilities. Many fall squarely within the 
domain of “science-based manufacturing.” 

Software error correction is one of the longest running lines of research in my 
laboratory, and this research has been especially useful to industry. When this 
work began, improving the performance of coordinate measuring machines and 
machine tools almost always required making expensive changes in the design, 
physical construction, and mechanical workings of the equipment. At the time, 
industry considered the idea of software error correction too risky, and didn’t 
pursue it. Now, after many generations of improvement in the performance and 
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costs of computing hardware, software-based methods for improving machine and 
process performance are really coming on. 

The potential of modeling and other software-based methods for improving 
machine-tool performance may reach full flower in this monster or in any of the 
growing variations of the still experimental hexapod machine tools. Hexapod 
technology— or, more broadly, parallel-design machines— represents a radical 
departure from traditional machine tool design. The jury is still out on whether it 
will live up to theoretical expectations, but one of the technology’s principal 
virtues is that it’s well suited for the Information Age. For hexapods, accuracy 
depends mostly on the control and coordination of the strut movements. This 
makes them very computer intensive, which could be an advantage. It’s much 
easier to change software instructions to improve performance and correct errors 
than it is to change mechanical components. 

Right now we’re working with a handful of companies to characterize the 
performance of this machine and to develop evaluation methods. We participate in 
a Hexapod Users Group, which includes most of the makers of parallel machine 
tools, several prospective manufacturing users. Department of Energy laboratories, 
and a number of universities. Stay tuned. In the not too distant future, NIST 
intends to provide you with the option of checking out the technology from your 
desktop computer or workstation. More on this later. 

Integration 

Now, let’s move from the brawn and sinew of machine tools on to the brains. 
Today, machine-tool control— in fact, industrial process control— is an area of 
intense interest. It’s poised, I think, for remarkable advances, especially in two 
areas: closed-loop processing and open architectures. 

Continuing progress in computers, sensors, software, and mathematical modeling 
presents incredible opportunities for predictive, closed-loop process control. You 
can already find some places where it’s used. Not many, but a few, and they’re 
likely to be proprietary, or highly customized systems, built with controllers and 
other components that have closed interfaces. 

So, if a manufacturer wants to upgrade or revamp his system, add a new capability, 
or otherwise change it, he’d better have deep pockets and time to spare. He’s 
either going to be locked into buying a product, often at a premium, from the 
maker of his controller— if it has the application he’s after. Or, he may have to 
spring for customized system integration— the software equivalent of gum and 
baling wire, except that it’s tremendously more costly. Then there’s the problem of 
lugging the growing accumulation of one-of-a-kind legacy software into the 
future. 
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All of us in this room recognize the value, the promise, and the potential of 
integration-not only at the level of process control, but in all facets of 
manufacturing operations. But, for the moment, let’s stick to control-specifically 
machine-tool control. Ideas for new applications are everywhere, and prospects 
for new capabilities are tantalizing. There’s been an explosion of innovation in the 
area of sensors and actuators, presenting amazing new possibilities for intelligent 
process control and even opportunities to innovate and to create value. 

Yet, I’d bet that companies are devoting more resources to application 
maintenance than to pushing the envelope, or to pursuing new, more robust 
approaches to control. And when a company does venture into new application 
realms, its engineer or programmer becomes a modern-day Sisyphus, pushing this 
growing boulder of legacy software up the hill to the next highest level of 
automation. Like the cartoon character “Popeye,” some companies are saying, 
“That’s all I can stands, and I can’t stands no more!” Their answer to all of the 
legacy software is, “open architecture”--not a classic Popeye response, I grant you. 
But a few years ago, this kind of response would have been considered just as 
fanciful as a cartoon. 

We are, I believe, in the early stages of an evolution toward open architectures and 
standard interfaces for controllers. To add momentum, we at NIST are working 
with industrial partners to clear technical obstacles to “plug-and-play” 
interoperability. In business terms, what a shift from “closed” to “open” 
architecture means is a shift from a market with relatively few players to a 
diversified market— a situation that usually benefits the customer. That’s how the 
U.S. automakers and major aerospace companies see the situation. We’ve worked 
with both types— at Boeing and at GM (General Motors). And we’ve worked with 
Mat Shaver, proprietor and sole employee of his garage-based machining 
operation outside of Baltimore. Think of him as representing a “tier four or five” 
supplier. 

Researchers in my laboratory have developed a prototype open-architecture 
controller. It serves as a testbed for evaluating standardized interfaces designed to 
accommodate interchangeable hardware and software components. Now, with a 
PC-based controller and standard interfaces. Mat Shaver, for example, can 
comparison-shop. He can search for the best value. 

That’s a significant advantage. He told us that a 40-megabyte hard disk from a 
controller vendor sells for about $1,700. When he first contacted us, an 850- 
megabyte, floor-hardened disk drive for a personal computer sold for about $300, 
which was 20 times the capacity for less than one-fifth of the price. Now you can 
get 1.5 gigabytes for about $300, and that’s about 40 times the capacity for less 
than one-fifth the price. And you just know it won’t stop there. 
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Multiply these prospective savings, and it’s no surprise that some manufacturers 
have begun to push for open architectures. The “Big 3" U.S. car manufacturers 
and their aerospace counterparts have formed the Open Modular Architecture 
Controller (OMAC) Users Group to develop specifications for software interfaces, 
or application programming interfaces. 

The job of developing these candidate interfaces has been assigned to a working 
group of industry and government engineers and scientists, including several from 
NIST. Besides members of the OMAC Users Group, our collaborators have 
included Advanced Technology and Research Corp., a company that recently 
introduced an open architecture controller based on the NIST work, and Real Time 
Innovations, a company that sells a software development tool that can be used for 
designing open architectures. 

To further this evolution, we will continue to focus on measurements and tests for 
evaluating and validating prototype standards. We’re concentrating on priority 
applications identified with the guidance of industry groups, including a 
consortium we formed last year. And as standards are formalized, we will develop 
tests and tools that will help controller manufacturers and software vendors ensure 
that their products conform with standards, a role NIST has performed for nearly 
100 years. 

In the controller area, the interfaces that ultimately do achieve broad industry 
acceptance will likely be a combination of market-dictated choices and standards 
crafted by consortia and formal standardization bodies. Because of the diversity of 
industries and needs in the manufacturing sector, several standard controller 
architectures may result. But we’re heading in the right direction— from what was 
once dismissed as a manufacturing pipe dream toward controllers with software 
‘hooks’ that enable competent programmers to affect real-time control processes. 

This is a matter of great strategic importance to manufacturers all over the world, 
as indicated by standard architecture initiatives mounted in Europe and in Japan. 
Clearly, it is in the self-interest of companies to be active in the standards arena. 
Through their participation, companies can ensure that the resultant standards 
work to their advantage — or, at least, not to their disadvantage. 

This is especially important in light of the fast pace of change in technology in 
today’s global economy. International standards are no less critical today than 
yesterday. International standards facilitate trade; national standards in many cases 
are barriers to trade. With technology changing so fast, we need to find new, more 
efficient ways to agree on standards and establish mutual recognition of traceable 
measurements. And we need to work together to accomplish this. 
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Information Technology 

If spending patterns are any indication, American industry is in love with 
information technology (IT). According to one 1996 estimate, U.S. companies 
spent more than $200 billion on IT hardware alone— “more than they invested in 
factories, vehicles, or any other type of equipment.” When software, networks, 
support and maintenance, training and other related expenses are taken into 
account, U.S. industry’s total IT bill is about $500 billion. 

What’s motivating industry’s spending binge on all this information technology- 
on all this “cool” stuff? A vice-president from a very, very large software company 
explained it this way to a Silicon Valley audience: “Cool, is a powerful reason to 
spend money.” I suspect there’s a not-so-small grain of truth here. But obviously, 
the primary motivators are: 

• gains in productivity, 

• greater customer-responsiveness, 

• better performance, 

• new organizational and manufacturing capabilities, and 

• competitive advantages. 

Although many companies use their IT tools quite skillfully, on the whole, 
industry’s investment in IT is not yielding full value. In large part, this is because 
we lack the means flexibly to integrate processes, functions, systems, and 
companies on small and large scales. 

For example, our research shows that, today, there are more than 400 software 
products billed as manufacturing and production engineering tools. Some of these 
simulation, modeling, and other engineering support tools are powerful 
applications for a particular function or a small set of functions. But these tools 
are largely incompatible with one another. Engineers re-enter data as they move 
back and forth among applications, which can lead to errors or to decisions made 
on the basis of information that’s out-of-date or just plain wrong. 

How much more useful these applications would be to your engineers— and to your 
business— if they were part of an integrated manufacturing tool kit. Regularly 
updated data would flow seamlessly among various software applications within a 
common computing environment. Elements of a shared database would range 
from production-system requirements to product, process and equipment 
specifications and from cost estimates and budget spreadsheets to plant layouts and 
set-up illustrations. 

In fact, we’re working with the users and makers of production-engineering 
software to develop and demonstrate a prototype integrated environment . 
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Participating companies include Black and Decker, Boeing, Raytheon, Deneb 
Robotics, Cim Technologies, and Adra Systems. Several government programs 
and universities also are involved. Later this afternoon, youTl hear about one 
aspect of this research from Rangan Krishnamurthy. Last year, he worked as a 
guest researcher in the Manufacturing Systems Engineering Group in my 
laboratory. 

So, with regard to manufacturing applications of information technology, we have 
a vision that we’re pursuing in our laboratories and with our collaborators. It’s a 
shared vision. And the National Research Council captured this vision best, 
perhaps, in a study from which we get this quote: 

“The vision for 21st-century manufacturing presumes that interconnecting 
manufacturing applications will be as simple as connecting household 
appliances— one need only know how to run the application . . . and 
manage the interface . . . The ease of interconnection and interoperation 
extends from devices found on the factory floor to applications 
connecting the factory to the product design facility to applications 
connecting an enterprise to its suppliers and customers . . .” 

We’re pursuing this vision through our National Advanced Manufacturing Testbed 
(NAMT). The NAMT really is about the future, about building the technical 
means to make the most of advances in the performance of computing, 
communication, and networking technologies. This is a job that must be tackled 
collaboratively, and the NAMT is designed to facilitate that kind of effort, in the 
style of the next phase of the Information Age. 

With industry’s guidance, we’ve designed the NAMT to serve as a vehicle for 
building information-based-manufacturing’s equivalents of roads, bridges, 
interchanges, and even mass transit rails. It’s a multi-node, multi-project testbed, 
built on a state-of-the-art, high-speed computing and communications 
infrastructure. NIST serves as the “virtual host” to remotely located collaborators 
from companies, universities, and government laboratories located around the 
country. Through the NAMT, for example, you will be able to evaluate a new 
control algorithm on the NIST hexapod, while sitting at the computer in your 
laboratory or home office. 

We’re addressing real manufacturing problems here, but the solutions must meet a 
requirement that goes beyond the immediate “fix.” By that I mean all projects must 
yield solutions that are modular, integratable elements of larger systems. In so 
doing, NAMT research and demonstrations will contribute to an open set of 
standards, interfaces, architecture specifications, and other infrastructural elements 
that enable varied sets and subsets of manufacturing systems to work together. 
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Here’s an example, the focus of a newly begun consortium. The objective is to 
develop the basis for virtual machine tools and inspection machines—computer 
models that behave exactly like the real McCoys on the factory floor. That 
capability would go a long way toward eliminating the communication gap 
between design and manufacturing, and shortening cycle times. You could cut 
digital bits before you cut metal to make certain that the first real part you make 
will be within specs. 

Think of it: you’d be able to optimize use of your own machinery. Manufacturers 
would be able to avoid costly, eleventh-hour surprises, like the unexpected need to 
build new tooling or change a design. And, you’d be able to assess accurately 
whether prospective suppliers have the resources and capabilities to deliver parts 
that are within design specs. 

What do we have to do to reduce virtual machining and inspection to industrial 
practice? We need to develop tools and standardized building blocks. We need 
computer models that represent actual machine behavior, mathematical 
representations of part geometry, more powerful machining and inspection 
algorithms, common data formats, and remotely accessible performance-data 
repositories. These will be the outputs of NAMT research, and many will be 
offered as the starting points for industry standards. That’s an essential feature of 
the NAMT. 

The value of information technology lies largely in connections, in links between 
applications, resources, and facilities. This is why NAMT projects emphasize 
developing the means quickly to assemble and reassemble these linkages. This is 
also why collaboration is so essential. Standards are the means to achieve 
interoperability, modularity, and reconfigurability, but they cannot be developed in 
isolation. This is the unifying theme of the projects already under way at the 
NAMT and of those yet to come. 

The promise of information technology for manufacturing is, in fact, bright. But 
there are clouds. I’ve mentioned a few-lack of interoperability, bulky legacy 
applications and data, and costly maintenance. Looming even larger on the horizon 
is the question of whether smaller manufacturers— suppliers-will have the 
wherewithal to embrace and deftly apply advanced Information Age technologies. 
If suppliers don't join OEM's (original equipment manufacturer) in making the 
transition to information-based manufacturing, the benefits realized from 
investments in IT may be marginal. 

I’ll conclude with a rather pedestrian observation: What I find most noteworthy 
about modern manufacturing is the sheer and growing diversity of its parts, even 
as the larger companies cull their tiers of suppliers. The business of manufacturing 
has evolved from the equivalent of one-man bands and simple combos to 
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incredible orchestras that play on a world stage. To be sure, the capabilities of 
individuals and their instruments remain important. But the tuning, the timing, and 
the arranging of a vast number of contributors are now absolutely critical to the 
quality and success of the performance. Today, it’s not enough to be a virtuoso in 
one domain. This means that while building their proficiencies and investing in 
their own instruments, manufacturers must also think like they’re members of 
orchestras. While paying attention to the overall score, they must also attend to the 
details of how best to perform with others, like--for example— developing the 
interface standards that will enable each participant in a distributed manufacturing 
enterprise to enter on time, and on key. 

I’ve already strained the analogy, I know. But information technology, I believe, 
is fundamentally changing the ecology of business, redefining the nature of 
competition, and placing a high premium on cooperation. Often in the arena of 
information technology, we’ll discover that what is good for all performers, can be 
even better for one. It will be best, however, for the firms that are most skilled and 
most savvy in understanding all aspects of the performance. 

Thank you for listening and my best wishes for an excellent meeting. 

‘ Certain commercial equipment, instruments, or materials are identified in this paper in order to 
specify the experimental procedure adequately. Such identification is not intended to imply 
recommendation or endorsement by the National Institute of Standards and Technology, nor is it 
intended to imply that the materials or equipment identified are necessarily the best available for the 
purpose. 
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Abstract 

A major issue for the automotive industry is the shortening of the time required to 
develop new vehicles. A very effective way of solving this problem is changing to 
a setup where development processes are based on digital information. To this end, 
companies are taking positive steps and using information technology (IT) to 
enable reforms to processes. 

Understanding the limits to the effectiveness of this strategy if each company 
merely carries out its own activities, the year before last, the Ministry of 
International Trade and Industry (MITI) established of the V-CALS Consortium 
with the cooperation of the automotive and information industries. This project 
implemented demonstrations and research into such matters as the promotion of 
standardization for the development of basic information technology and for 
information distribution, both of which are required to enable digital processes to 
function. As a result, the project was able to confirm the effectiveness of digital 
processes and provide recommendations regarding the prerequisites to the 
formation of digital processes (for example, new generation PDM). 
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1. AIMS OF V-CALS 

In the processes from vehicle planning to preparation for production, V-CALS 
aims to minimize the amount of trial manufacture in the development stage, and to 
enable work processes, that is "digital processes" in which products can be directly 
produced in a world without trial manufacture and paper drawings. To this end V- 
CALS has: 

1) clarified the problems and issues relating to the current situation that are 
impeding digitalization, and 

2) clarified the use and requirements of a common information system base that 
can solve such issues the problems 

V-CALS is also developing new generation information systems in 
appropriate fields and implementing demonstrations and research into the 
effectiveness of new work setups. 

2. OVERVIEW OF V-CALS 

To enable the above aims to be realized, in May 1996, 32 companies including five 
automotive companies, five information companies, and 22 parts suppliers set up a 
consortium. Its actual activities were divided into four areas for which separate 
working groups (WGl through WG4) were established to carry out the following 
demonstrations and research. 

WGl was further divided into two subgroups (SGI 1 and SGI 2). SGI 1 
used the most advanced current technology to trial digital processes and clarified 
the prerequisites for enabling the processes. Parallel to this, SGI 2 conducted 
research into the tools (PDM) needed to enable the actual new generation of digital 
processes to be realized in a way that fulfilled the prerequisites provided by SGI 1. 

WG2, WG3, and WG4 implemented demonstrations of standards that 
form the basis of digital processes, set standards, and developed and evaluated 
translators. 

Specifically, WG2 conducted demonstrations in the application of 
AP203 and AP214 in STEP. WG3 researched the application of the industry 
standard EDI for receiving orders for mass production. WG4 was divided into two 
subgroups. SG4I converted motor vehicle maintenance manuals into SGML, and 
SG42 placed all types of national regulations and information relating to motor 
vehicles onto a database, and demonstrated systematization, standardization, and 
application. A diagram showing the working groups and their functions is given in 
Figure 1. 

The results of the activities of each group are reported below. 
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Figure. 1 Functions of V-CALS 



3. TRIAL OF DIGITAL PROCESS (WGl/SGll) 

3.1 Purpose 

The purposes of the trials are to apply current CALS technology into business 
processes related to the development of motor vehicles and to clarify the 
effectiveness of digital processes and issues relating to them(Figure.2). In the 
demonstrations, a virtual enterprise was created using participating companies and 
focusing on all phases from the development of vehicles to the preparation for their 
production. Using the most advanced current IT, the group clarified how far 
current technology would go in developing vehicles in a virtual world and 
extracted the problems that remained (gap between virtual and real worlds). 
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3.2 Overview of Trials 

Trials were undertaken for the following three reasons: 

1) To verify the effectiveness of digital mock-ups and extract related issues 

In the digital process, all parts in a motor vehicle were expressed as three- 
dimensional models in a computer. These were used for design investigation. 
The three-dimensional digital models that were used instead of drawings are 
called digital mock ups (DMU). The group then examined how useful these 
DMUs were as replacements for actual vehicles. 

2) To verify the effectiveness of electronic conferences and extract related issues 
Electronic conferences and electronic design reviews overcome the restrictions 
of time and space. Attempts were made to determine how effective they were 
in reducing development periods. To this end, asynchronous and synchronous 
electronic conferences were held using a wide-band network, their 
effectiveness tested and related issues clarified. To verify the effectiveness of 
digital management and extract related issues 

3) Delivery management, progress management, and design change management 
in the virtual enterprise was conducted based on digital information. The 
effectiveness of digital management was tested and related issues extracted. 
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3.3 Results of Trial 

(1) Digital mock up trial 

Testing of functions for expressing "product appearance" 

The functions used to create digital clay models for conceptual designs were 
basically effective. For a particular amount of work and time a full-size clay 
model of the same quality could be made for the same type of conceptual design. 
In particular, in the initial design stage where details are not shaped and where 
investigation of the conceptual design is not particularly stringent, digital clay 
models could be made efficiently in a short time using these functions. 

However, because the modeling methods used in these functions are 
analytical (planar construction must be reduced to cross-sectional level), they are 
not suitable for use (are not intuitive) in conceptual design where overall vague 
creativity is required. 

It is also difficult to investigate a detail design when the precision of a 
life-size model is provided and use after the intermediate stage of design is not 
practical. 

Editing functions such as surface connection, cut, redraw, copy, and 
partial change are simple to use, are precise and enable trial and error of digital 
clay models. This was seen as the strength of the digital clay models. However, 
the partial change function was, compared to the clay model, not free or flexible 
enough for design work where impromptu trial and error is common. It would be 
easier to remake the model than to use this function. 

When there are many trimmed surfaces, the amount of data increases 
and becomes difficult to handle. 

Testing of functions for expressing "three-dimensional form" 

The effectiveness of creating and editing functions for digital models of curved 
surfaces was tested. 

Forms were recognized and differentiating functions were very 
effective. The legibility of form was better than in drawings. 

Adequate functions for editing three-dimensional forms and data are 
provided and there are no problems with ease of operation, reliability, and 
response. 

In the drawing of cross-sectional forms, a great deal of work is required 
in paper drawing and there is a great difference in the precision of such drawings 
as produced by experienced and non-experienced persons. The digital functions 
however are able to provide highly accurate cross-sectional drawings in three- 
dimensional forms for complex parts, regardless of the operator. 

Note however, that editing greatly impacts the process in which three- 
dimensional data is created and the work involved in editing models is 
disproportionate to the scale of the design changes and so, in may cases, there is 
reliance on the data creation process. In practice, a lengthy training period will be 
required to enable efficient editing. 
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Testing of effectiveness of functions for expressing the "operation of 
multiple parts". 

We tested the effectiveness of writing and editing functions for digital 
models of moving parts. 

We were able to test the effectiveness of functions for expressing the 
"operation of multiple parts" and found that it was possible to design the mobile 
footprints required in the design of mobile parts. However, where restrictive 
conditions are defined for models, functions that can directly revise design without 
having to be concerned about the deletion of restricting conditions, changes to 
form, and definition of restricting conditions are required. Other functions 
required are those that enable easy visualization of restricting conditions. 

When digitalization takes place, even when the scale of a model 
changes, such as when in the past a clay model had to be re-created, the fimctions 
can respond with flexibility and speed, conceptual trial and error can be checked 
simply, positioning between parts can be intuitively understood and any 
interference simply detected, and models can be quickly tested by people 
associated with the next process or people in non-design departments. The 
effectiveness of these was acknowledged. 

On the other hand, there are a great many limitations to the digital 
process including a lack of functionality prerequisites, the amount of work 
involved with digitalization, the load of excessive data, and the load on the 
equipment. 

In the primary demonstration, verified technology was used as the 
required technology and so the first step in the digital process, that is digitalization 
of the "product" was done almost perfectly with current technology. 

However, problems start to mount when we look at the practicality of 
digitalized information, in particular when the field of vision is extended to include 
the sharing of information between corporations - that is the CALS concept. 

(2) Electronic conference trial 

Meetings that would conceivably occur during the digital processes, such as 
meetings for instructions, making contacts, conferencing, and reviewing, were 
conducted using a combination of synchronous (video conferencing using PCs), 
asynchronous (document based conferencing using electronic notice boards), and 
mobile conferencing. The effectiveness of such conferences was evaluated and 
technical problems extracted. 

(3) Digital management trial 

We report on the results of the trial of design change management, the central 
theme in the digital management demonstration. In this demonstration, we used 
the "production preparation design change function" and "parts design change 
function" developed for this demonstration to digitalize the preparation for 
production work of motor vehicle manufacturers and the design and preparation for 
production work of parts manufacturers. The following demonstrations were held. 
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and their effectiveness evaluated. 

The results showed reduction in time required to deal with issues and a 
reduction in the work involved. This resulted in increased productivity. 

Specifically, there were variation depending on the different stages of 
the work but nevertheless, the work involved in follow-ups between jobs was 
reduced by half. 

Also, the work flow was visualized in the evaluation. This enabled the 
processes to adhere to rules and reduced duplication. Furthermore, work 
management was made more efficient by linking management of product 
information to the work flow. Redundant work time was eliminated and work 
results were more uniform. 

As shown above, digitalization of the parts design and preparation for 
production work enables work to be automatically received on the network and 
enables more efficient management of the entire work flow. The effectiveness of 
this procedure met with approval. 

3.4 SGll Summary 

The primary demonstration enabled an evaluation of the theoretical effectiveness 
of digital processes, centered around digital mock ups. In addition, current 
problems were clarified. This is an important step towards realization of digital 
processes. 

4. SG12 - NEXT GENERATION PDM RESEARCH 

4.1 Aims of the SG12 

To halve development time, the shape of future digital processes was mapped out 
and requisites for a new generation of PDM extracted. Prototypes were developed 
and demonstrations implemented using basic IT. The practicality of these was 
tested. 

4.2 Next Generation Development Processes and PDM 

In the development of vehicles the development processes, from initial product 
planning through to preparation for production, traditionally have overlaps in the 
sequential flow. However, in digital processes that use data, in all digital 
development stages of the digital design audit, digital mock up, digital laboratory, 
and the digital factory, everything can be studied in an interactive manner using 
data definitions and growth. Therefore, the existence of a so-called digital car 
where everything can be defined digitally is important. This car is known as the 
product object of a motor vehicle. Essential elements for the progress of 
development, which will enable this product object to evolve and grow, have been 
identified as cooperative design and co-evolution management. We therefore 
conceived a new generation of PDM that would enable response to the large scale 
global distribution that is characteristic of automotive development and that would 
provide a multi-dynamic view in which all sorts of knowledge will be accumulated 
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as agents. (Figure .3 ) 
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Figure.3 Next-Generation Development Process and PDM research 

To respond to the goals of V-CALS, which are to promote standardization and 
digitalization of product information to enable a response towards a development 
environment that is becoming more global and more distributed, even more 
advanced cooperation is required in the new generation of automotive vehicle 
development. To meet this need, we defined product objects, cooperation design 
aid, and co-evolution management as basic concepts that will help realize the new 
generation of automotive development. 

In the new generation of automotive development, product objects will 
be recorded on data bases and shared using CORBA technology. Cooperative 
design functions that define product objects will be standardized as work objects. 
Furthermore, by enabling the visualization of product information alongside the 
development process, a development environment is made in which all people 
associated with the development can grasp an overview of the purpose and state of 
development of a product. 

In addition, a virtual development space is created in cyberspace by 
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digitalization of product objects, work objects, and development process 
definitions and mutual cooperation is promoted at the same time. This allows for 
evolution of the motor vehicle development process. In the new generation of 
automotive development we aim to replace the relic of the past age of mass 
production where many people were divided into different labor groups, with 
sharing of product objects using a new generation PDM, and creative automotive 
development enabled through highly precise engineering that utilizes the help of 
cooperative design functions. 

4.3 Configuration of Next Generation Vehicle Development System 

After looking at the information and technical requirements for a new generation 
digital process, we created a four-tiered system configuration as shown in Figure 4. 
There are four levels, the presentation and application level, the design, object, and 
service level, the distributed object base, and the database base. As before, there is 
a distributed object level, which uses CORE A as its key technology, between the 
application and database levels. It is characterized by the inclusion of a design, 
object, and service level that acts as a system parts interface group for improving 
the productivity of future applications. 






Figure.4 System Configuration 

A requirement of a database platform is the ability to enter products into the 
database. In order to define a database, that supports common vehicle design 
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activities, a BPR is required that is capable of organizing an immense amount of 
data. Figure. 5 shows that the database platform, we are using STEP, AP203, 
AP214 as a model for implementing the OODB. And we developed an application 
interface that is comparable to AIM in STEP. 



Enter product configuration definitions in DB 

Stu(fy API that is aware of product configuration informatio 

Based on STEP (AP203, 214) 
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Figure. 5 Product Configuration DB based on STEP 



Next trial theme is parallel processing function. This is very effective approach for 
quickly accessing specific data from a vast sore of information that is scattered on 
many distributed servers. Since the retrieval object is launched in parallel on the 
target server, this system will yield dramatically better performance than single 1- 
to-1 connections. 

The third is collaborative concurrent engineering capabilities. Taking the layout of 
an engine room as an example, complex engine and transmission systems are only 
the beginning, for body shape data and tires data must also be accessed at the same 
time. 

In order to provide the virtual design support capabilities, we developed a powerful 
viewer to support design work based on a digital mockup, shown Figure. 6. 
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Figure.6 Virtual design support function 

The product object will be at the core of next-generation vehicle development, and 
the tool needed to render the product object. A 3-D browser capable of rendering 
three-dimensional shapes and a configuration browser that can handle parts 
configuration data are required. Correspondence between trees and shapes(part 
recognition) should be achieved quickly by browsing operations illustrated 
Figure. 7. 



57 






NcxM»cnoratlon Browser 



iiiigincering fund ions 



i hclw^ctn ircc$ md lipC'i f pari rtc^giVAuM I 




Figure.7 Next-Generation Browser 



4.4 Results of Trials 

In the trials, we tested the "product object search engine functions" and the 
"cooperative design aid functions" used to test the distributed BM model for motor 
vehicles around which the database and distributed levels are centered. 

(1) Results of trial of product object search engine functions 

We evaluated the differences in search functions for product objects on the 

distributed OODB to find the following: 

• Differences between concentrated and distributed types 

• Total number of parts found 

(100,000, 500,000, 1,000,000) 

• Differences in call-back of search results 

(1, 1,000, 5,000, 10,000) 

• Differences between single search and parallel search 
The test patterns can be broadly divided into three groups: 

• Product configuration search (following data pointers) 

• Simultaneous attribute search using multiple servers 

• Detailed measurement of performance for each of above bases (by data 
base, CORBA, application) 



58 




a) Results of product configuration search 

The aim for performance was to operate a simple system within two seconds. The 
results, including results other than those, were within two seconds, so we are able 
to say that the goal was achieved. The following can be said after viewing the 
trends of the results: 

• The total number of hits does not depend on performance. 

• There is no difference between concentrated and distributed types. 

In the single search for product information (search following pointer), the above 
results exhibited the effectiveness of the OODB 

b) Simultaneous search using multiple servers 

The results of searches where a part attribute was used as a keyword in a number 
of servers separately and in parallel are followings. 

For operations with a high processing load, we aimed to finish the 
search in 30 seconds. This goal was achieved for up to 10,000 hits but 
performance deteriorated when more hits were obtained with the search taking 
close to 60 seconds. This is a result of the time required for network transmission 
of a large number of search results rather than a result of search processing 
performance. In this demonstration we used the lOObaseT and lOBaseT but a 
faster network is required. 

In the parallel search, results were equal to approximately 20% of the 
single search. In later demonstrations we achieved a further 20% improvement but 
this is probably a true indicator of parallel processing. 

c) Analysis of performance by level 

The database search performance was greatly affected in each level. In the parallel 
search, processing was halved because the search processing was distributed and 
the search load was lightened. The more servers the better the results. 

When we view the results above for a), b) and c), all cleared the 
performance goals and were able to hold up to practical use. As expected, parallel 
searches were more efficient. However, in the actual field of automotive 
development design, the environment will be a number of times more complex 
than the one in the demonstration. An improvement in database access 
performance and in network speed is desirable. 

(2) Results of demonstrations of cooperative design aid functions 
a) Details of demonstrations 

In relation to the functions developed as above, a demonstration was implemented 
using actual automotive parts data. The items tested are listed below. 

1 . Compression rate for form data 

2. Conversion time for form data 

3. Form display and configuration display time 

4. Time required for simple form operation 
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5. Single part display time 

6. Effect of associative buffer 

7. Engineering functions 

b) Evaluation and issues raised 

We set goals and evaluated these based on the work requirements for the new 
generation of automotive development. 

1 . Both data compression rates and conversion times were within the target 
values so we were able to confirm the effectiveness of this system. 

2. Likewise, form display and configuration displays were within the target 
values and so we were able to confirm the effectiveness of this system. 
However, the target for simple form operation was not reached. This was 
not only because of the software. We recognize that there is a need for a 
major technical revolution in terms of hardware. 

3. As can be seen, the associative buffer enabled a great decrease in search 
times. However, the associated setup needs more research and the 
associative hit rate needs improvement. We also confirmed the 
effectiveness of information links between browsers. It will be important 
in the future to expand the fields of application and create a setup in 
which designers can appropriate information freely. 

4.5 Summary of SG12 

(1) Adoption of proposal in OMG 

In February 1998, results of this study were adopted in the OMG. It was 
wonderful that these demonstrations were able to test the systems and also 
contribute to international standards. 

(2) The future 

The demonstrations only provide a basic setup for realizing a "new generation 
PDM". In the future we would like to continue investigations at the practical level, 
and verify practicality and clarify related problems associated with the new 
generation PDM. The results would be used as guidelines for the future. 

5. OTHER TRIALS AND RESEARCHES 

In this V-CALS project, the demonstrations and research described above were 
implemented. In addition, the following items were demonstrated, as explained 
above. 

• STEP standardization aids (WG2) 

• Standard EDI for motor vehicle industry (WG3) 
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• Motor vehicle maintenance information network system (WG4 - SG41) 

• Motor vehicle legal and regulation information database system (WG4 - 
SG42) 

Because of space limitations, the results of these shall be published at another time. 

6. REVIEW OF V-CALS AND FUTURE PROSPECTS 

The activities of the V-CALS Consortium ended in March 1998, three years after 
its establishment and after two years of practical work. In this project, we have 
been able to achieve a great deal. In particular, it is significant that we were able to 
create an actual prototype, even though imperfect, using the best of the current IT 
tools. 

Through work that attempts to build a bridge between the virtual and the 
real worlds, we were able to clarify the types of technology, standards, and work 
reforms that are required for the future. 

The Japanese Automobile Manufacture's Association (JAMA) will 
establish an Electronic Information Committee in April to look at standardization 
activities. This committee will promote activities that make practical advances in, 
and that disseminate STEP, EDI, and SGMI in the automotive industry. 

A suitable organization that will inherit the results of this practical 
research and conduct further research in this field is currently under discussion. 

I hope that information companies that participated here, will use these 
results to create a next generation CAD and PDM technology for use throughout 
the world as commercial software. We really hope that this research will be 
followed up. 
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Abstract 

Sandia National Laboratories’ Product Realization Environment (PRE) is a 
lightweight, CORBA-based framework for the integration of a broad variety of 
applications. These applications are "wrapped" for use in the PRE framework as 
reusable components. For example, some of the PRE components currently 
available include: our product data management (PDM) system, our human 
resources database, several finite element analysis programs, and a variety of 
image and document format converters. PRE enables the development of end-user 
applications (as Java applets, for example) that use these components as building 
blocks. To aid such development, the PreLib library (available in both C++ and 
Java) permits both wrapping and using these components without knowledge of 
either CORBA or the security mechanisms used. 



Keywords 

CORBA, integration, framework 




1 INTRODUCTION 



Like many organizations, Sandia National Laboratories has a variety of distributed 
electronic resources. The most apparent or these are databases: financial, human 
resources, product, etc. However, there are other important electronic resources: 
engineering design advisors, finite element simulators, data format converters, 
manufacturing devices, etc.). Sandia’ s Product Realization Environment (PRE) is a 
lightweight, CORBA-based framework for the integration of this broad variety of 
electronic resources. 

Figure 1 illustrates the general idea. Each of these applications) is "wrapped" to 
plug into an enterprise-wide wiring harness (illustrated by the grid). This wiring 
harness and associated "wrapper" let the application be used as an enterprise 
component. Using this wiring harness, a PRE client can, for example: 

• Put data into the component. 

• Get data out of the component. 

• Request that some computation be performed. 

Furthermore, these components might use services provided by each other. For 
example, structural analysis component might retrieve the model to be analyzed 
out of the PDM (Product Data Management) component. It might then put the 
analysis results back into the PDM for archival purposes. 

An end-user interacts with the PRE system through some kind of user interface 
(a Java applet on a Web page for instance) which accomplishes its tasks by 
utilizing these wrapped applications as components. Such a user interface might 
be very general, giving access to all of the components in the system. More likely, 
however, its use is more special-purpose: utilizing a few components to do specific 
task via a simple interface. Note that the operation might itself be quite 
complicated, requiring co-ordination of several of these enterprise components. 
Using PRE, however, we can present a simple user interface to this task. 




Figure 1. Application integration with PRE 
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The PRE framework is based upon the Common Object Request Broker 
Architecture (CORE A), which provides industry standards for writing plug-and- 
play software. These standards are promulgated by the Object Management Group 
(OMG), a consortium of hardware and software vendors. In implementing PRE, 
we have used the CORBA-compliant Orbix product from Iona Technologies. 

Thus, the CORE A foundation on which PRE is implemented is a component 
technology. The CORE A standard specifies how to create and use a software 
component: 

• How to specify its interface (COREA IDE). 

• How to discover and name the (possibly remote) component. 

• How to make a request of the component (down to the order of the bits on the 
wire). 

Using COREA, a developer can create a very wide variety of these software 
components. The FRE framework, built atop the COREA component technology, 
specifies which interfaces a developer should implement. That is, it specifies 
things like “If you are an application, then this is exactly the interface you must 
implement.” A client programmer can then easily use your application component, 
since all applications provide the same interface. Many ideas in PRE borrow from 
the Discus project at Mitre (Mowbray, 1995). Further, it captures experience from 
our previous work in enterprise integration (Friedman-Hill, 1996), and in agile 
manufacturing (Whiteside, 1996). 

2 PRE ARCHITECTURE 

The major components of the PRE architecture are illustrated in Figure 2. This 
captures the same concepts illustrated in Figure 1, but exposes some of the 
structure in the communications grid of that figure. In the upper right of Figure 2 
are the applications that are “wrapped” to run in PRE. These are used by the user 
interfaces to provide end-user functionality (illustrated in the upper left). These 
end-user interfaces employ the wrapped applications and the PRE Core services 
(the lower part of the figure) to deliver functionality. 

The major pieces of the PRE architecture called out in that figure include the data 
transport, the integrated applications, user interfaces, the trading service, the 
conversion broker, and security. 

2.1 Data objects 

COREA and the PRE data object provide the basic data transport mechanism in 
PRE. All applications integrated into PRE accept their inputs, and emit their 
outputs as PRE data objects. A data object is a container for structured 
information, and is essentially an associative array of named properties. Methods 
are provided for getting and setting values of properties. A property can be a single 
number or string, or it can be a multi-megabyte data file. Based on this simple 
structure. Data objects can be used to represent simple documents, C-like struct 
objects, tabular information, etc. A MIME string is used to denote the type of a 
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User interfaces Wrapped applications 




Figure 2. Major elements of the PRE architecture 



PRE data object. Using MIME types to describe content has a number of 

advantages: 

• MIME is an internet standard for describing types of things. Web browsers 
already use these types for figuring out how to render data, thus our data 
object integrates nicely with the World Wide Web. 

• The browser’s database for MIME types already provides a mapping of MIME 
types to applications that end users have already had to deal with once. Our 
desktop GUI can use this to decrease installation complexity for deployment 
(since we’ll need the same kind of information). 

• The MIME format permits electronic mail to include enhanced text, graphics, 
audio, and other types, in a standardized and interoperable manner. Future 
plans include the transmission of PRE data objects via multimedia mail. 



2.2 Wrapped applications. 

All of the real functionality in PRE (the useful computation) is provided by the 
various applications wrapped and integrated into the framework. Application 
“wrappers” integrate these into the PRE framework, making these applications 
useable as programming components. User interface developers then use these 
components to accomplish tasks desired by the end-users. 

All applications integrated into PRE support the same interface, consisting of six 
methods. Thus, the first tasks of an “app-wrapper” is to understand the 
functionality of the program being integrated into PRE, and to decide how this 
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functionality should be mapped onto these six PRE application methods. Here are 
the six methods in the PRE application interface: 
convert ( ) . If part of the functionality of the application can be viewed as a 
type conversion, then it should support the convert method. PRE applications as 
data converters have turned out to be a very extensively used aspect of PRE. A 
Web page, “Conversion Central” has seen substantial use at Sandia, mostly for 
conversions among various image formats Q.e., TIFF to GIF, CAD format to 
VRML, many formats to PDF, . . .). 

Another use of the convert method has been in wrapping legacy applications. 
Many of our old engineering and design FORTRAN programs, for example, can be 
usefully viewed as conversions from an input deck into output results. 

query () . The query method is implemented by applications with data that 
can be queried. Certainly wrapped databases fit into this category, but other 
applications might be query-able as well. 

get_data ( ) . Servers that can emit data on demand implement this operation. 
For example, a word processor application integrated into PRE might implement 
get_data to permit retrieval of the current document. Our PRE interface to 
Sandia’ s Product Data Management (PDM) system provides this method as a 
mechanism for retrieval of documents from the PDM. 

put_data ( ) . This is the inverse of get_data: if a client might want to “put” 
some in data into your application, implement the put_data method. For 
example, our PRE interface to the PDM implements this to enable clients to add 
new documents to the repository. 

execute ( ) . This operation is for scriptable aspects of an application. Thus, 
applications with a script language should implement execute to give client 
programs access to this functionality. Further, the signature of the execute 
method is very general, so that any kind of application functionality that does not 
fit cleanly into one of the other categories can be provided through this method. 

launchO. If an application is being used, for example, to perform a data 
format conversion, then it is not particularly desirable to have the user interface 
(UI) associated with that application be displayed to the end user. Indeed, it would 
probably be distracting. In some cases, however, displaying this UI to the end user 
is the whole point of the operation. The launch method us used by a client 
program to explicitly state that the application in required to present its user 
interface to the end user. 



2.3 PRE Trading service 

The PRE Trading service provides a “yellow pages” registry of the component 
applications available in PRE. Although there is now an official OMG interface to 
this type of service, our design of the PRE trader predates this, and we do not 
conform to the standard. Future versions of PRE will address this incompatibility. 

Applications integrated into the PRE environment register with the PRE Trader 
so that they can be discovered and used by others. These “others” might be client 
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programs that will discover and use the component automatically, or human 
developers who can use the component to accomplish some task. 

The kinds of things registered at the PRE trader include general information 
about the application, as well as details of operations supported by the application 
(convert, query, etc.). The kinds of general information available for each 
application include: 

• Name: A one-word description of the component. Suitable for display, for 
example, on a button. 

• Summary: A one-line description of the component. Suitable for display, for 
example, in a status line. 

• HelpURL: The location of the on-line help for the component. 

• Email-contact: An address to which to send gripes (or kudos!) 

The other information registered at the PRE Trader about each application 
consists of the list of methods implemented by the component, and the data types 
appropriate to each. For example, the Conversion Broker (described in the next 
section) uses this information to use conversion services dynamically added to the 
PRE environment. 



2.4 Conversion broker 

A client that wishes to use a PRE component to convert a data object from one 
type to another (from some CAD format into VRML, for example) should take the 
following steps: 

• Query the Trading service to see if any PRE component has advertised such a 
conversion capability. 

• If an appropriate component is available, call its convert ( ) method to 
effect the conversion. 

The PRE Conversion Broker simplifies this task by handling the trader query 
automatically. You can ask the Conversion Broker to perform any conversion. It 
doesn’t actually implement any conversions itself; it merely queries the trader on 
your behalf, and uses the resulting PRE application to do the conversion. The PRE 
Conversion Broker provides a simple interface for converting data from one type 
into another. 

The Conversion Broker provides another bit of value-added as well. Suppose 
that one PRE application has advertised its ability to convert from type A into type 
B, and another PRE application advertises the conversion from type B into type C. 
In this case, a query to the Trader for a conversion from type A into type C will 
yield no hits: no application has advertised such a service. However, the 
conversion is, in fact, possible by converting first into the intermediate type B. 
The Conversion Broker is able to carry out such sequences automatically if no 
direct conversion is available. Merely call the convert ( ) method on the 
Conversion Broker, and the required sequence of conversions will be carried out. 
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2.5 Security 

The PRE security architecture supports a number of different security models, 
selected by plug-able library modules. Our basic approach has been to secure the 
PRE framework, not to construct a security mechanism that can be used by 
CORBA-based systems in general. The approach can be summarized as follows: 

• Define and implement methods that can be used by the initiator and acceptor 
to negotiate a mutually acceptable security model and establish a security 
context if necessary. 

• Pass a security token, the contents of which will depend upon the security 
model to each method in the framework. 

• Perform the necessary security operations (authentication, authorization, 
delegation, data protection). 

• Handle as much of the security as possible within PreLib development 
libraries. 

• Allow the application owner to control access to his application and to 
perform authorization external to the framework if so desired. 

The PRE security system provides for the use of a number of different security 
models. How the security system functions is dependent upon the security model 
that is agreed upon by the initiator (client) and the acceptor (server). The system 
provides a mechanism for the client and server to negotiate a compatible and 
agreeable security model, although in most cases the environment will dictate the 
security model. 

The client can request that a particular security model be used. This allows the 
client to request the use of a model other than the default model of the server. This 
will most often be used to allow the client to request a higher level of security than 
that usually used by the server. The server, however, has the final choice about 
which security model is to be used. 

The security models that are supported in the latest release of PRE are shown 
below: 



Model Name 
SEC_MODEL_NONE 
SEC_MODEL_NAME 



SEC_MODEL_DCE 



Description 

essentially turns off the security system 
uses unauthenticated username and hostname, but 
exercises most of the functionality of the security 
system, including logging 

uses the DCE implementation of GSSAPI to perform 
authentication, authorization, and delegation 



The three security models reflect the phases in the development of the PRE 
security system. The first model, SEC_MODEL_NONE, was created to allow 
applications to exist without security. It enabled the development and initial 
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implementation of the security methods without requiring any code changes on 
behalf of application developers. This model can still be used to turn off security. 

The second model, SEC_MODEL_NAME, provides an intermediate step 
between no security and full security. When using this model, a context is 
established between the client and the server, although the context is not secure. 
The security token contains information about the context, from which the client’s 
username and hostname can be determined. The client’s information is not 
authenticated and cannot be relied upon to enforce serious security requirements. 
However, this model can be useful in a stand-alone environment or when security 
really isn’t an issue. Furthermore, the extensive logging performed when using 
this model can provide some insight into the operation of the system. 

Based upon DCE, SEC_MODEL_DCE offers a full range of security services 
including authentication, authorization, and delegation. Encryption is not currently 
enabled, although that is a capability of the system. On many networks, using a 
wire-encryption mechanism such as SSL could better perform encryption. If it 
turns out that encryption inside the framework is necessary, it can be enabled. 

Java servers and applets 

To support the use of Java servers and applications with DCE, the necessary hooks 
into the security system have been implemented using the Java Native Interface. 
This allows Java servers and applications to utilize the security services and inter- 
operate fully with C+-H clients and servers. 

To support the use of applets, a secure proxy has been developed that works in 
conjunction with DFS Web Secure from IBM to allow applets to access a DCE 
server. When a user requests access to the applet, DFS Web Secure authenticates 
the user and stores the user’s DCE credentials securely on the server. Information 
about the credentials is passed to the applet via a parameter. The credential 
information is then added to the security token and passed to the secure proxy. The 
proxy can then use the user’s credentials to establish a secure context with a DCE- 
based server and securely invoke its methods. 



3 IMPLEMENTATION ISSUES 



PRE consists of five facets or layers: 

• The PRE CORBA interface definitions in the OMG Interface Definition 
Language (IDL). 

• Official implementations of some of these services. 

• The Framework Developer’ s Kit (FDK) Libraries (PreLib) 

• User-developed server applications integrated into PRE 

• User-developed interactive client applications. 

Each layer refines the concepts developed by the layer below it. This structure has 
made it possible for the functionality offered by PRE to evolve, sometimes 
dramatically, without invalidating end-user code. For example, the CORBA IDL 
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definitions have changed as PRE has evolved, but because application developer’s 
code is targeted toward PRE’s libraries and not directly to the CORBA layer, this 
code did required no modification. Furthermore, the layered structure has made 
user code relatively insensitive to changes to (and bugs in!) third-party software at 
lower layers. In the following sections, we will examine the contributions of these 
layers to PRE, stating at the lowest level. 

3.1 PRE CORBA interfaces 

PRE’s CORBA interfaces are quite simple - they comprise a total of eight 
interfaces, fourteen global types, and sixteen exception types. The interfaces are 
designed so that they can be easily used as building blocks for more complex 
structures. Full details of these interfaces are available in html format in the PRE 
distribution and at www-collab.ca. sandia.gov/pre/fdk/idl. The html was 
automatically generated by idldoc (Friedman-Hill, 1997). 

The PRE Interfaces 

Common: Ancestor to all other interfaces. Common contains operations for basic 
security, retrieving version and meta-information, and initializing and destroying 
objects. 

Data: As described above, PRE data objects provide the basic data transport 
between components in PRE, and use the MIME standard to describe content. The 
MIME standard also allows for utilization of local formats that are not internet 
standards. Such local type or sub-type names must begin with "x-". This will 
certainly be useful in holding input data for various applications (for example, 
application/x-antipasto, for input to the antipasto program). PRE also 
define several new main types. These include x-structfor C-like structures and 
X- table for tabular data. 

Observer: A simple object, similar to Data but capable of holding only one 
property. The Observer interface is used for asynchronous notification: the single 
property is used as a representation of the status of some operation. 

App: The fundamental actor in PRE; all services will export this interface as a 
means of offering their functionality. This interface adds to Common the set of 
standard App methods (convert, query, etc.). Each of these operations also 
exists in an asynchronous form that accepts an Observer as a third argument. The 
App interface serves as ancestor to all the remaining interfaces. 

Trader: Serves as a database of meta-information about a PRE installation. The 
PRE Trader contains descriptions of the capabilities and locations of installed 
Apps, and details about the various x-struct and x-table MIME types that have 
been defined. 

AppFactory: Creates App objects. Because AppFactory inherits from App, it 
can implement query ( ) to respond to status requests, for example. 

DataFactory: Creates Data objects. Again, can implement App methods: for 
example, query ( ) to locate existing Data, put_data ( ) to move Data objects 
between factories, convert() to alter existing Data objects. The DataFactory uses 
the Trader to learn how to construct Data objects of various MIME types. 
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ObserverFactory: Creates Observers. This interface allows processes to initiate 
asynchronous processes and quit, because such a process can obtain an Observer 
object from an ObserverFactory; this Observer object can then monitor the status 
of the asynchronous process. 

3.2 Official implementations 

Several of the PRE interfaces are represented solely by privileged implementations 
that, together with PreLib, form the PRE runtime system. These include official 
implementations of the DataFactory, the Trader, the File Manager, and the 
ConversionBroker. Additionally, there is a standard ObserverFactory service, 
which some of the other core services use in their implementations. In this section 
we discuss some implementation issues and experience related to these services. 

Our implementations of these interfaces are all in C++ and are available on 
Sun/Solaris, SGI/IRIX, HP/HPUX , IntelAVindows 95, and IntelAVindows NT. 
These are installed on the Unix boxes using our own installation system called 
“AppPkg”. On the Windows platforms we provide self-installing executables 
build with the InstallShield product. 

The Data Factory. 

The standard Data Factory offers Data object persistence (the presence of which is 
implied in the IDE) and several optimized data transfer modes (which are not 
specified in IDL.) Furthermore, it itself is implemented as a library, so that end- 
user applications can contain an embedded Data Factory for efficiency reasons. 

The standard Data Factory optionally offers simple object persistence. The 
implementation is completely hidden from users of the service, and indeed, 
persistence has been implemented in several different ways. Our initial 
implementation was in terms of a simple relational database, and used the popular 
shareware product Mini SQL (see http://www.hughes.com.au). Production usage 
demonstrated that installing a Data Factory that depended on the presence of an 
external RDBMS was problematic. Thus, the current implementation uses flat file 
data storage, offering increased performance and simplified installation. 

The standard PRE Data Factory also offers a mechanism to transfer a set of 
properties in a single network transaction. Recall that data object may contain 
many properties, and the PRE IDL a remote procedure call for the retrieval of 
each. In the case of array or tabular data where hundreds of individual properties 
must be retrieved, this leads to severe inefficiencies of the Data Factory library, it 
is used only by the PreLib layer, and are invisible to the applications programmer. 
It should be noted that this optimized transfer mode is not part of the public 
interface 

The File Manager. 

Another form of optimized data transfer is the handling of single Data properties 
that are very large. Some of our engineering applications, for example, have multi- 
megabyte inputs and outputs. The PRE File Manager is an implementation of the 
App interface that manages a flat file space of these large files. When a Data 
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property is set to contain a large file, the property in the Data Factory actually will 
contain only a pointer to a file owned by a File Manager service. The decision to 
store a file in the File Manager is made by PreLib, and is invisible to the end user. 
The File Manager can either use CORBA to transfer the data, or it can use a 
separate authenticated TCP connection (Pyarali, 1996); while the former is more 
convenient when firewalls are in use, the latter is more efficient. 

A further optimization is possible if the programs exchanging data happen to be 
located on the same machine. In this case the File Manager can allow end-user 
applications to get direct access to the files in the File Manager’s store. Again, the 
decisions about when this is feasible are made by PreLib, so that two 
communicating applications do not need to know when they are collocated; the 
applications can be written in a location-independent way, and get the benefit of 
optimization when it is possible. 

The Trader. 

The PRE Trader is a simple interface to an underlying RDBMS. Again, details of 
the implementation are hidden, and several alternatives have been tried. An initial 
implementation, using Mini SQL, resulted in some of the same problems observed 
for the Data Factory. Currently our Trader is implemented using an in-house 
embedded RDBMS library, offering simplified installation and maintenance. 

PRE Apps and MIME types are described in a small language named TREG’ 
(Trader REGistration). A TREG description of an App or type is presented to the 
Trader via the do_register ( ) operation. This information is then available for 
querying via the Trader’s query ( ) method. 

The Observer Factory. 

The standard PRE Observer Factory service is a simple implementation of the 
CORBA ObserverFactory interface that adds Observer persistence. Persistence is 
implemented via the standard Data Factory library. The observers implemented by 
this factory merely store the status information given to them; end-user 
applications can retrieve it at a later time. 

3.3 ThePREFDK 

The PreLib libraries insulate the applications programmer from the details of 
PRE’s CORBA-based implementation. There are two parts to PreLib: the client 
libraries and the server libraries. Client libraries are used to communicate with 
other PRE entities; the server libraries greatly simplify the act of writing a PRE 
server application. 

PreLib is available in a number of languages. The full library is available in both 
Java and C++, while the client-side library is also available in Perl and Visual 
Basic. 

Client libraries. 

In PRE, every operation must be authenticated via the security system. This 
important function can be difficult to accomplish correctly and consistently. 
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Furthermore, even if done right, these security details can often obfuscate the 
actual purpose of a method call. Therefore, PRE’s security functionality is handled 
for the programmer by PreLib. 

There is a PreLib class (in C++ and in Java) for each of PRE’s CORE A 
interfaces. For example, the PreData class represents Data objects, and offers 
methods to set and get properties. The PreData class also handles, for example, the 
dispatching of large Data properties to the File Manager service, or the use of 
multiple-property transfer modes. Similarly, there are PreApp, PreTrader, and 
PreDataFactory classes for communicating with the corresponding PRE entities. 

Additionally, PreLib offers a number of convenience classes. For example, a 
PreConverter class allows the programmer to easily use the Conversion Broker 
application. A PreTable class provides an interface to tabular data which is 
implemented entirely in terms of the underlying Data interface. Classes named 
PreLocalData and PreLocalTable provide the programmer with a simple interface 
to the multiple-property transfer modes of the Data Factory. 

Each method call to a remote object made via client-side PreLib hides a great 
deal of complexity from the programmer, including security, manipulation of 
COREA data types, use of COREA functionality to locate remote services, etc. As 
a result, our users’ code has remained insulated from out underlying 
implementation of PRE. 

Server libraries. 

The PRE server-side libraries provide the same kind of simplification for server 
programmers as the client-side libraries do. The details of the security system, and 
of COREA itself, are entirely hidden. Writing an application is reduced to the task 
of inheriting from a simple PreLib class (in C++ or in Java) and implementing only 
the methods that are of interest. This class is then manipulated by the real COREA 
stub classes, provided by PreLib. This arrangement allows for not only the security 
to be handled by PreLib, but also exception propagation, argument conversion, etc. 
In addition, by default, the asynchronous variant of the core App methods are 
handled by all servers with no effort on the application programmer’s part: 
notification is handled by PreLib. 

3.4 Server applications 

As developers use PreLib to users integrate more applications into the framework, 
the functionality available in PRE grows. The current set of applications integrated 
into PRE is rather diverse. Illustrating the range of applications type, these apps 
include: 

• Databases: Access and Mini SQL. 

• Thermal, structural, and optical analysis packages 

• Our Product Data Management system 

Also available is a range of data format conversion applications. Applications that 
convert among image formats have proven to be very popular PRE components. 
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PRE servers can be written in either C++ or Java, and generally arise in the 
following way. A programmer wishes to meet some functional requirements of an 
end user. He finds several components already available in PRE that are useful in 
providing this functionality, but some pieces are missing. He wraps a new 
application for use in PRE, because integrating it with existing PRE components is 
the fastest way to get the job done. The result is not only that the initial problem is 
solved, but also the newly wrapped application is available for future developers. 

3,5 End-user functionality 

The final piece of PRE is a client program that provides some kind useful 
capability to an end user. There is a larger set of implementation languages 
available to client developers than to application wrappers. Though C++ and Java 
are certainly available, client authors can also use perl (widely used by cgi-bin 
programmers) and Visual Basic: it’s particularly fun to watch a PRE application 
run from an Excel spreadsheet. However, because of the ubiquity of Web 
browsers, most of the current PRE clients are implemented as either Java applets or 
as Web pages backed up by cgi-bin programs. 



4 CONCLUDING REMARKS 

PRE is deployed, production software. In addition to its use here at Sandia 
National Laboratories, PRE is installed and in use with several other projects. As 
part of a Cooperative Research and Development Agreement (CRADA) with 
Goodyear Tire, Inc, PRE is being used to help produce an integrated tread wear 
design environment. At Georgia Tech, PRE is in use as a testbed for the National 
Electronics Manufacturing Initiative (NEMI) plug and play framework definition 
project. In another CRADA (EUVL: Extreme Ultra Violet Lithography), PRE is 
being used to help develop a design environment for next-generation 
semiconductor manufacturing. 
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Abstract 

The MiViPoRo framework offers a general systematisation of knowledge in 
domains where work involves the interaction of processes in both the physical 
domain and the information infrastructure. For the domain of engineering and 
manufacturing the framework assumes a further division of the cybernetic domain 
and the physical domain into activity layers for observations and operations 
(manufacturing), and improvements and innovations (engineering). 

Mobile software agents, on the other hand, form a new paradigm for the 
implementation of flexible communication, computation and coordination services 
in loosely coupled distributed systems. 

This paper will look into the architectural characteristics of both approaches 
and it will compare and contrast them. Both approaches are fit for complementary 
purposes, making their merging an attractive option. 



Keywords 

Enterprise models, product life cycle models, proxy possible flow semantics, 
mobile agent architectures. 




1 INTRODUCTION 

Recently, many developments in the area of business processes have taken place, 
vv^hich were made possible by advances in the field of communication and 
information technologies. Business processes nowadays rarely are confined to a 
single production site, but often involve several companies, thus creating extended 
or virtual enterprises. These developments have led to the emergence of (parts of) 
business processes which are completely virtual, i.e. they don’t have a physical 
counterpart, such as standard manufacturing processes. 

Adaptation (or evolution) of frameworks can be done in a number of ways. 
One way is to extend the framework to encompass new areas of interest. Another 
way is to merge complementary frameworks to create a more general one. In this 
paper we take the second approach and explore the possible merger of two 
frameworks: the MiViPoRo framework and the Mobile Agent Framework 
(Dalmeijer, 1998, Hammer, 1998). The MiViPoRo framework {Modules for 
innovations, Versions for improvements, Proxies for operations, Records for 
observations) has been introduced as a mean to connect work (engineering, 
manufacturing) to an information infrastructure in (Goossenaerts, 1997a). 
MiViPoRo conformant system specifications have a so-called proxy possible flow 
semantics (PPFS). Proxies are unique representations of physical objects or entities 
which flow through an information infrastructure. These proxies are resident on a 
network of model execution engines, in “reflection” of the represented physical 
objects flowing through the physical domain (see Figure 1) (Goossenaerts 1997b). 
The Mobile Agent Framework (Dalmeijer, 1998, Hammer, 1998) has been 
introduced to provide an infrastructure for flexible communication and 
coordination services in loosely coupled distributed systems. 

Whereas in MiViPoRo the mobility of proxies in the information infrastructure 
strictly mirrors the mobility of the physical entities in the physical domain, where 
the manufacturing processes are being carried out, mobile software agents do not 
have such a constraint. In fact, the freedom of mobile agents from the physical 
constraints of place (in the information infrastructure) is akin to two other values 
that the cybernetic domain adds to the physical domain. These values are the 
possibility to store data on past events (performance) in support of reporting 
(memory), and the possibility to work with expected future system states, events or 
their abstractions in support of planning and scheduling (simulation). Software 
agents move in the cybernetic domain, free from the constraints in space and time 
that physical entities have by necessity, and the constraints that proxies have by 
choice (in the MiViPoRo architecture). 

However, the mobile agent framework of (Dalmeijer, 1998, Hammer, 1998) so 
far has been focussed on providing an infrastructure for agents to move in. It does 
not provide a systematic framework for capturing knowledge about agents and the 
objects they interact with. Such a framework is provided by MiViPoRo. 
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Figure 1 The relation between the physical and cybernetic domains in 
MiViPoRo. 

Both frameworks appear to be complementary, making their merging an 
attractive option. In this paper we will explore how the two frameworks can be 
merged and why it is advantageous to do so. 



Overview 

The MiViPoRo framework and the mobile agent architecture will be presented in 
sections 2 and 3 respectively. 

In section 4 we will examine the two alternative architectures by looking into 
the following issues: 

1 . Interaction model for mobile software agents and proxies; 

2. Migration protocols for software agents and proxies; 

3. Directory and trading services; 

4. Inference services. 

To illustrate the various concepts involved we will use a small case from a 
manufacturing context. 

The PC order process case 

To illustrate the application of the MiViPoRo and mobile software agent models 
we present a case called the ‘PC order process’ (van Stiphout, 1998a, 1998b), 
featuring the assembly to order of PCs. The ‘PC order process’ consists of the 
following process steps (Figure 2): 
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1 . An order for a PC is entered into the system. The order specifies what CPU, 
memory and hard disk the customer wants. 

2. After the order has been received, the PC is assembled. 

3. Parallel to the assembly process, the customer is sent a bill. 

4. When the payment of the bill is received, this is registered. 

5. After the PC has been assembled and payment has been received, the PC is 
shipped. 

If we look at the ‘Assemble PC’ activity we see that it in turn consists of a number 
of smaller activities: 

1 . Insert CPU. 

2. Insert memory. 

3. Insert hard disk. 

The process consists of two streams: the production stream dealing with the 
actual assembly and shipping of the PC, and the administrative stream dealing with 
the financial aspects of the ordering process. 




Figure 2 PC order process. 



2 THE MiViPoRo FRAMEWORK 



The MiViPoRo framework {Modules for innovations, Versions for improvements, 
Proxies for operations. Records for observations) (Goossenaerts, 1997a) divides 
the problem domain of enterprise integration into two sub-domains and four 
activity layers (Figure 3). The sub-domains are: the physical domain comprising 
the physical space, time and matter, with artifacts, goods, agents, and cells (spatial 
units) having their lives in it; and the cybernetic domain which adds memory. 
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communication, monitoring (including knowledge-capture) and control 
(computations) services to the physical domain. The activity layers cover 
observations, operations (manufacturing), improvements and innovations 
(engineering). 

Physical and cybernetic domain and their interflow 

On the physical side, the term ‘entity’ refers to an artifact, agent (person, machine) 
or place that has a definite physical existence in itself. At any point in time, an 
entity is present at exactly one place. It is characterized by an existence in matter 
and a facility to move in space (with the possible exception of immobile places 
such as assembly stations). A (physical) agent has powers that determine the 
actions it can execute. Entities are grouped in classes on the basis of similarities in 
their time, space and matter situated possible lives (the PC as a specification, the 
PC in various states of assembly, the PC in its box on the way to the customer). At 
a point in time, the place (cell, organization unit) where an entity is located, will 
accommodate certain possible or required life phases of the entity. This set of 
possible life phases may change as the entity progresses from one place to another 
and determines the events in which the entity may involve next. An entity has a 
life span, a succession of space-time situated events in which other entities may be 
involved as well (e.g. when the PC is assembled, the tools at the assembly station 
are involved in its life span). 

In the example (see Figures 1 and 2) artifacts are, for example, PC’s being 
assembled, or the (paper) bill sent to the customer. Examples of agents are 
technicians doing the assembly and sales representatives entering the order, billing 
the customer, or registering the payment. There are also cells (places) such as the 
desk where the order is entered, and the assembly stations, where the PC’s are 
assembled from parts. 

In the cybernetic domain the agents are represented by actors (agent proxy) in 
the form of, for example, user profiles with authorization to use various software 
applications for supporting order entry and billing, or for checking out (and 
locking) the work order for the PC to be assembled next. An artifact is represented 
by a prop (artifact proxy) such as the bill of material for the custom made PC and 
its assembly status. The possible life phases of an artifact are situated at cells or 
organization units. The requirements phase for the PC (the custom order) is 
supported by the sales department, the production phase (assembly) is situated in 
the manufacturing department and the transportation phase is supported by the 
shipping department (the PC is being shipped). Each step in Figure 2 coincides (in 
this case) with a life cycle phase. 

The modeling primitives on the cybernetic side are modules. Modules are 
created and transformed in the innovation layer. One module typically captures 
time- space-matter independent aspects (knowledge) on one possible or required 
phase of the life span of a class of entities. For example a module may specify a 
generic bill of material for a PC, detailing which type of components are present in 
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a certain (commercial) model. Modules are combined into a possible lives model 
or enterprise formula (EF) (Goossenaerts 1997b). 

Artifact possible lives models (APLM) model the possible life cycles of 
products. An APLM is a set of modules - each of which describes a possible life 
phase of the artifact. The modules in an APLM describe concurrent, successive, 
alternative or mutually exclusive phases in the possible lives of entities, as 
illustrated in the PC order case. One can view an APLM as a product centered 
workflow specification, with each module comprising the specification of a range 
of activities in which the product may or must be involved. 

An enterprise formula (EF) (Goossenaerts 1993) offers a modular description 
of the enterprise processes. It comprehensively specifies the operational roles and 
the coordination of persons, machines, parts and products making up an enterprise. 
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Figure 3 MiViPoRo’s activity layers, generic services, and modeling 
primitives. 

The term interflow (short for m/eractive flow) denotes the co-ordination and 
monitoring of the physical processes by means of computational processes. 
Obviously, when a hard disk is inserted in the PC, this has to be communicated to 
its cybernetic counterpart in order to keep the physical and cybernetic states 
synchronized. The concept of a computational process covers the transformation 
and storage of digital representations by computer programs. Models of artifacts 
and enterprises exist in the cybernetic domain. 



84 











The four activity layers 

The four activity layers span the two sub-domains and cover observations, 
operations, improvements and innovations. The discussion of the example case so 
far has been set at the operation layer. At this layer, the model execution engine 
connects repetitive work, action in the physical domain, to computations and 
communications in the cybernetic domain. 

At the improvement layer the version manager supports the evolution of 
versions of modules and the corresponding life phases. For instance, in the PC 
order process, the transformation of the order entry process into one that also 
accepts orders sent by email. 

At the innovation layer the innovation coach supports the concept of entirely 
new entity life phases (through the development of new modules and artifact 
possible lives models). Examples of entirely new life phases in the case of the PC 
order process are the introduction of laptop assembly, or multi-processor PC 
assembly. There is an assumption that design in the cybernetic domain precedes 
realization in the physical domain. 

At the observation layer the browser and report generators are used to create 
views of entities based on the records of their proxies. 

After their creation, modules and possible lives models can be employed in the 
operation layer and observation layer. Versions of modules and possible lives 
models capture modifications as they are performed in the improvement layer. At 
this level, for example, minor variations with respect to the generic module may be 
specified, such as various options on hard disks, CPU’s and memory. Major 
variations, such as laptop and desktop models, correspond to innovations and are 
dealt with at the generic level. At the operation layer, a proxy exists as a unique 
representative of a physical entity. It captures knowledge on the entity and the 
modules (each belonging to the possible lives model of the class of the entity) for 
which it has been earmarked. At this layer a particular PC’s components are set. 
For observation purposes, a record of a proxy is created in memory of the proxy’s 
past or current flow through a network of cells. This flow reflects the time-space- 
matter situated life span of the corresponding entity. Records are recorded during 
operation layer processes. 

MiViPoRo thus allows us to systematically capture knowledge about 
manufacturing systems, products and their representations in an information 
infrastructure. At present it has an emphasis on synchronizing between the real 
world system and the information system supporting and controlling it. This leaves 
unexplored possibilities such as dealing with processes that exist purely in the 
cybernetic domain. 
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3 MOBILE AGENT ARCHITECTURE 



The MiViPoRo framework is well suited for describing processes with hard 
physical constraints such as manufacturing processes, where physical objects (raw 
materials) are transformed into products by the components (milling machines, 
lathes, measuring devices) of the production system. In such systems, static agents 
are sometimes used (Zwegers 1997) to provide the flexibility needed to deal with 
disruptions of the process by unpredictable delays and other unanticipated events. 
These agents provide the intelligence for solving problems, but are immobile since 
they encapsulate the fixed components of the production system. 

In mobile agent architectures (Dalmeijer 1998a, Hammer 1998), the agents can 
move through the distributed system. Mobile agents are software components that 
perform a task for a client, which may be a human, or another software 
component. An example of such a task is the execution of a workflow, such as the 
PC order process. The agent receives a specification of the task to be performed, 
detailing the subtasks and their dependencies. The agent then deals with each 
eligible subtask in its turn, by locating the nodes in the network, where the services 
and other resources are provided that are needed for the subtask, selecting an 
appropriate one and then migrating there to have the work done. In some cases the 
task specification may involve subtasks that can be carried out in parallel such as 
the billing and registering tasks that can be done in parallel to the assembly task, 
and the agent then may generate clones for each subtask. These clones will, after 
carrying out their subtask, merge again if the task specification requires such, as 
Figure 2 illustrates at the point where the customer has paid the bill and the PC has 
been assembled and shipping can be started. 

As already suggested in the previous paragraph, mobile agents operate in a 
distributed environment, consisting of nodes, connected by a communication 
network. Such environments may have various topologies. For instance, a number 
of nodes may be connected by a very reliable and fast local area network. Such a 
collection of nodes is called a site. Sites may participate in a wide area network, in 
which the communication links between sites are much less reliable and slower 
than in a local area network. One can imagine that in a large company, the sales 
department is located in one place, the assembly facilities in another and the 
financial services in yet another place, each place corresponding to a site in a wide 
area network. Mobile agents are able to move reliably through such a distributed 
environment. In particular, migration is failure atomic: it either succeeds or the 
agent stays at its current place (Dalmeijer, 1998b; Hammer, 1998). Mobile agents 
therefore will experience little hindrance from unreliable services or 
communication links. They therefore can operate in environments where some 
links or even nodes may not be available from time to time. This can occur either 
by accident or on purpose as in the case of hired lines or mobile computers. A 
mobile agent is also able to wait for a resource or service to come up again or for 
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the connection to the site it wants to migrate to, to become available again. In 
addition, it has the ability to look for alternative sites, where it can carry out its 
task. For instance, when an agent is assigned the task of fulfilling a certain order, it 
must find a place where the PC can be assembled. When all technicians are busy, 
the agent must wait until a technician becomes available and then migrate to the 
place (assembly station) of this technician. 

Agents that can accept and execute tasks on the basis of a specification can 
communicate at a high semantic or knowledge level and thus are very flexible. 
Such agents generally use an Agent Communication Language (ACL) such as the 
Knowledge and Query Manipulation Language KQML that was developed in the 
context of the ARPA Knowledge Sharing Effort (Genesereth 1994). KQML is a 
container language for more domain specific languages such as KIF (Finin 1993) 
or SQL. KIF stands for Knowledge Interchange Format and is based on first order 
predicate logic. Agents that can operate at a semantic level require considerable 
intelligence. However, it is not necessary to put all this intelligence inside the 
agent. This would make the agents very large indeed, whereas the attractiveness of 
mobile agents stems for a large part from the fact that they can be kept small (by 
programming them at a high level of abstraction) and therefore do not pose a big 
burden on the communication infrastructure. Instead, the necessary functionality 
should be made available by static (immobile) services. 

In each node of the network, seryices are offered to the agents. Every node 
should offer an interface that agents can use to communicate with the system 
components present at the node. Such an interface is often called a dock. One of its 
functions is to encapsulate the local components to hide their heterogeneity and 
make them accessible to the agents using the ACL. Docks may also support the 
security of the system, by providing authentication services, and support agent 
migration by providing reliable, secure transportation services to the agents. The 
system should also offer generic services, such as directory services, needed to 
locate agents and components, and trading services needed for an agent to find the 
nodes where a particular services is offered. The latter services may vary from 
node to node. One node could offer access to a particular database, another access 
to a CAD/CAM system or other applications. A third node mightoffer an inference 
service that an agent could use to make a choice between a number of options, 
such as which particular service to select given a budget, costs, timing, and other 
constraints. 

Mobile agents provide a generic approach for the integration of heterogeneous 
distributed systems. They create an infrastructure for doing work in distributed 
systems and thus for building virtual or extended enterprises. For this to succeed 
semantic integration of the component systems has to be supported. The agents 
and the component systems have to share a common context (or ontology) such 
that the semantics of their interactions is unambiguous. At present, the mobile 
agent framework of (Dalmeijer 1998a, Hammer 1998) does not provide a 
systematic way to capture the required knowledge. At this point, MiViPoRo 
provides the necessary complement. 
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4 MERGING MiViPoRo AND MOBILE AGENTS 



Deployment of mobile agents in a MiViPoRo conformant system can be done in 
several ways of which we will present two extreme cases. In an actual system both 
extremes and any variant in between may occur, depending on the scope and the 
range of the process that needs to be supported and on the available infrastructure. 
The first example considers a so called lean mobile agent that fully relies on its 
operating environment. Another example is a fat agent that can operate with only a 
minimal support from the environment it works in. Both types of agent may act on 
behalf of or even completely replace a physical agent. 

First, consider a lean mobile agent that operates in a completely open and 
homogeneous infrastructure. The software agent can then rely on the required 
resources (such as knowledge and functionality) needed to execute its task being 
available locally. It needs to contain only the specific knowledge to carry out its 
task, such as the proxy of the physical agent it represents, and any modules needed 
to maintain global knowledge about the task that it is to carry out. This agent 
would make use of the model execution engines, which play the role of a dock, in 
the cells it visits to execute the transformations that go with the task it has to do. 
The application of such agents could result in a more flexible production process, 
when the agent would, for example, be able to find its own route through the cells. 
For example, think of an agent that could detect the load on assembly stations and 
adjust its route accordingly. In our example, it could propose to first have memory 
inserted and then the CPU into the PC. In such an infrastructure, the mobile 
software agent is an alternative to having the system components communicate 
with each other in order to coordinate the creation of a particular product. The 
agent would provide the (mobile) control and pass the necessary information (such 
as production parameters) to the system components involved at the right time. 
Note that a physical agent can start off any number of software agents to perform 
tasks. These software agents all act on behalf of the physical agent and thus have 
to carry (a copy of) the proxy of this agent with them to have access rights to 
information and services at the nodes. Such a parallel execution of tasks can only 
happen in the cybernetic domain. 

Software agents may also be used to perform activities that have no direct 
counterpart in the physical domain, such as exploring possible future or past 
activities to come up with a new plan or solution in the case of a disruption of the 
systems operations. Such a plan, if adopted by the physical agent, may have an 
effect on the physical world. These applications provide an enrichment of the 
MiViPoRo framework. 

Next consider a fat mobile software agent, that is, a software agent that has all 
required functionality on board. In terms of the MiViPoRo framework, such a 
mobile software agent can be thought of as a compound entity, comprising 
modules, certain proxies (e.g., of money or information products), and the model 
execution engine(s) needed to transform proxies of its own, and proxies in the 
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environment. Such an agent will not depend too much on the presence of model 
execution engines at the cells it visits or local knowledge to carry out its task. In 
fact, it would be possible for such an agent to carry out its task with only the 
minimal amount of interaction with the modules and proxies in the cells it has to 
visit. This would make it possible for the agent to flow through an infrastructure 
consisting of systems offering only limited interfaces for communication and 
limited support for functionality. An example of such an infrastructure is that of an 
extended or virtual enterprise, where only a limited extension of the local 
infrastructure can be afforded. It then is the agent’s task to coordinate the 
collaboration between the autonomous companies involved and to constitute the 
integrating factor. Communication in such a situation would have to be at a high 
semantic level to bridge all the syntactic and semantic differences present in such a 
heterogeneous system. 

Interaction model for mobile software agents and proxies 
In all cases, communication between the software agent and the proxies of the cell 
the agent is visiting is necessary. Since the proxies in a cell are under the control of 
the local model execution engine, that is, the model execution engine present in the 
cell, communication between a mobile software agent and a local proxy would 
involve this model execution engine. In case the mobile agent carries its own 
model execution engine, this would have to communicate with the one in the cell. 
Model execution engines in MiViPoRo posses this property, since it is also needed 
when a particular proxy flows from one cell to the next and the model execution 
engine of the cell the proxy is leaving hands control over to the model execution 
engine of the cell it is flowing to. 

Migration Protocols 

In the framework of Dalmeijer ( Dalmeijer 1998a, 1998b), each node an agent can 
visit contains a generic piece of infrastructure (sometimes called a dock) that 
provides the necessary services for migrating agents, and also for creating or 
destroying agents on the basis of well defined protocols and criteria (such as 
budgets being available). These services are also relevant for migration of proxies 
and should be made a generic part of the local model execution engines present in 
each cell. 

Other Services 

Other services that need to be part of an infrastructure supporting mobile agents 
are directory and trading services that tell an agent where a particular entity (cell, 
agent) may be found and what services are available respectively. Optional 
services include inference services that an agent needs when it wants to find the 
quickest route through a network of cells or the fastest way to rush a particular 
order through the production network. 
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5 CONCLUSION AND FURTHER WORK 



Knowledge systematisation for engineering and manufacturing, and co-ordination, 
communication and computation in a heterogeneous network are two different 
dimensions of an information infrastructure. By examining MiViPoRo and the 
mobile software agent architecture, we found that the ability of software agents to 
autonomously perform various tasks on behalf of their creators (ultimately 
physical agents) can be exploited in at least two ways. Software agents can travel 
between various machines of a distributed system; and they can explore alternative 
future courses of activities (simulation, scheduling) for the interflow processes. 
MiViPoRo offers a systematisation of knowledge on interflow processes 
(interaction of physical agents and cybernetic domain processes). The mobile 
software agent architecture adds to this support for pure cybernetic domain 
processes with no necessary involvement of physical agents, and hence a freedom 
of the space-time-matter constraints that restrict interflow processes. Moreover, a 
system architecture including mobile agents makes the cybernetic domain system 
adaptable and easily extendable. 

The discussion in the previous section has touched on a number of possible 
scenarios for merging the MiViPoRo framework and mobile agent architectures. 
Since they operate in the cybernetic domain, mobile agents can be used to carry 
out information production processes, in analogy with physical production process 
already described in MiViPoRo. Further research on how the MiViPoRo 
framework and the mobile agent architecture merge, has to focus on applications 
to non-trivial practical cases: (1) illustration of proxy flows and mobile agents in 
situations where multiple companies are involved such as in a virtual enterprise; 
and (2) illustration of improved flexibility in the physical system as enabled by the 
extendable functionality of the agent architectures. 

Other research will address questions such as when it is more effective or 
efficient to use a mobile agent, and when to use a proxy, in case both options are 
available. 
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Abstract 

Customer service is essential to maintain good and lasting relationships. Many 
companies would like to reduce the cost of such support services. They have been 
looking for solutions many of which are created using IT tools. This paper will 
discuss a generic approach using IDEF3 process modelling methodology to 
provide such services in a flexible fashion. The approach results in the definition 
of a framework consisting of generic modelling methodology and software 
systems which captures the knowledge of experts and generates customer support 
systems tailored to the application requirements. The framework allows 
personnel, who do not have computer programming background, to generate such 
systems easily and the information can be accessed anywhere in the world. 
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1 INTRODUCTION 

As the world’s economy becomes global, manufacturing operations are facing new 
challenges to improve their quality of the products and services within the 
complete product life cycle (Lee, 1994). The strategy to extend customer support 




from the usual design oriented supplier’s view to a comprehensive coverage 
beyond the sale and guarantee period of the product has emerged among 
manufacturers who operate globally and produce large equipment with typical life 
span of over 20 years. Manufacturers have to advise their customers on various 
aspects of their products and give guidance to on how their products can be 
operated, and when and how to do preventive maintenance. They also have to 
help customers on how to identify the causes for eventual malfunctions and how to 
repair them if the equipment fails. All these are imposing serious challenges to the 
manufacturer because the interactions with customers have to be done promptly 
and efficiently. 

Another issue which requires extensive research is how the support 
information should be organised for different kinds of people. A novice machine 
operator requires more detailed instructions than a trained one. People in different 
countries have been brought up in distinct traditions and education systems (Robin, 
1996). Their communication is hindered not only by language difficulties but also 
by cultural differences. The system should therefore be flexible and adaptable to 
the needs of the user irrespective of the differences involved. 

In the Globeman 21 project, which is part of the Intelligent Manufacturing 
Systems (IMS) international program, we look at the processes which are 
envisaged to be essential for manufacturing industry in the coming years. This is 
particularly important for products, which are investment in nature and whose 
operation is generally sophisticated, for example, the CNC machines domain. 

This paper describes an industry-led project to investigate a novel framework 
which integrates a number of technologies to provide after sales services to 
customers. Vendors can use the framework to build models which describe their 
desired patterns of remote operations support and subsequently generate the 
system which their customers will use. Experience in the application of this 
framework to a CNC machine manufacturer has achieved substantial savings in 
creating and maintaining the remote customer operations support system. 

The importance of the product (e.g. CNC machine) life cycle aspect could be 
seen from the revenue generated by maintenance and renewal business for the 
vendor. Traditionally, manufacturers concentrated their efforts in research and 
development to create the product which is superior in “cost to performance” to 
those of the competitors. The activities from the delivery of the product to the end 
of its life cycle are provided to an extent barely sufficient to keep the product 
operational for the satisfaction of the customers. The change in global market 
forces vendors to rethink about this philosophy. More and more vendors realize 
that provision of services related to the use and maintenance of the equipment is a 
tremendous opportunity to expand their business. A shipbuilding company 
estimated that the business generated after the sale till dismantling the ship, could 
be twice as much as the sale price of the product. Understanding such technical 
and economic impact and its technical components are therefore paramount for 
companies thinking on a global scale. 
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Similarly, the same concept can be applied to companies which design, 
manufacture and support large installations of their own. Their customers are in 
fact internal. They include operators, line managers and company management. 
The operational activities are those after the installation of the equipment and will 
be supported by the servicing team. Well organized operational and servicing 
support not only helps to ensure high efficiency and quality of the output, it also 
extends the usable life of the equipment so that more profits can be made. 



2 CHARACTERISTICS OF REMOTE OPERATIONS SUPPORT 

A significant difference in the characteristics of remote operations support services 
as compared to those activities prior to sales is that they often occur outside of the 
vendor company’s physical boundaries. In many cases, these services are 
provided remotely, that is, at a substantial distance from the vendor. A review of 
literature shows that most remote support services are concentrated on diagnosis of 
machines or the problems in the manufacturing processes. For example, control 
systems manufacturers have diagnosed faulty boards through telephone networks 
and ordered replacement parts (Huang and Wang, 1996). Diagnosis and support 
for marine operations can be done via satellite connections (Karsal et al, 1996). A 
good communication network and commonality of formats are essential 
requirements in both cases. 

On the other hand, the ability of the system to provide a good answer to the 
customer must be considered. Artificial intelligence techniques such as expert 
systems (Kim et al, 1996), neural networks (Chen et al, 1996) and many others 
(Patel and Kamrani, 1996, Chatwin et al, 1996) have been employed. Obviously, 
the final implementation of the remote operations support has to be integrated and 
the answers unified. 



3 SERVICES IN DEMAND 

In the one-of-a-kind product life cycle, many kinds of operations support services 
can be identified. The research in CSIRO has concentrated in four particular 
types, namely. Remote Diagnostics, Remote Expert Advice and Process 
Optimization, Remote Training and Remote On-line Manual. The outcomes from 
the research are integrated by the Framework for Integration of Remote Support 
Technologies (FIRST). 

Remote Diagnostics 

In Remote Diagnostics support, there are many non-controllable factors involved 
in the process, for example, changes in the conditions of the machine itself or the 
input materials. For these well understood processes, the ability to carry out 
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diagnostics remotely is less critical. However, for products built on less 
disciplined type of knowledge such as CNC operations, these factors are normally 
unpredictable, although in many cases are repeatable. However, the major 
problem with these approaches is that each of these remote diagnostics system 
normally involves experts from scratch. This proves to be expensive because they 
are one-off in nature. Experience also shows that knowledge gained in one project 
is not formally recorded and hence is difficult to be transferred to other projects. 

Remote Expert Advice and Process Optimization 

Expert Advice refers to the support service which provides advice to the user on 
what operating parameters can be used to achieve best results. It involves the 
search of a knowledge base which consists of engineering design knowledge, 
expert knowledge in scientific investigations, past operating results and rules to 
evaluate. 

In addition to field knowledge, there is also a need to incorporate new 
knowledge into the system as the technology develops. Existing systems are 
generally robust in this sense because they are often designed with a particular 
problem in mind and hence are deficient in the flexibility to accommodate 
structural changes of the knowledge representation. Substantial effort is then 
required to integrate the existing knowledge base with the new knowledge 
(Aamodt and Nyard, 1995). The changes in knowledge structure also impose 
problems in the delivery of the support to the customer. 

Remote Training and On-line Manual 

In order to maintain consistent attention from the trainees and system users, multi- 
media authoring tools are now available to create applications which can be used 
for self-training or as an on-line manual (Asymetrix Corp., 1995). These tools 
normally run on a PC and so are excellent systems for localized support. 
However, for customers and users who are far away, some other form of delivery 
has to be employed. For example, graphics information has been successfully 
displayed by hypertext technology for a local support situation (Koshy et al, 
1996). 

4 FORMAL MODELLING 

In general, the current approach to develop a remote operational support system is 
a four step process as shown in Figure 1. Initially, the expert of the machine 
process defines the operational topics to be supported. The description is then 
passed to a system analyst who will design the system to handle the requirements 
specified by the expert. This will take many rounds of discussions before the final 
format of the knowledge can be represented properly. Programmers are then made 
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available to the project to transform this idea to practices. When the system is 
completed, the result is released to the user. 
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Figure 1 Current process of remote operational support systems development. 

This approach suffers from the fact that each of the remote operations support 
systems are created as an individual developmental project. This is a time 
consuming and expensive process. The results are often simply a repetition of 
many basic components of some other applications but with specific adaptation to 
the new requirements. These repeated developments can well be picked up by the 
system automatically from previous projects so that the process of system 
development can be more productive. 

Moreover, the expert in Figure 1 does not have a direct relationship with the 
final remote operations support system. Hence, the person who develops the 
system is not the person who has the most relevant experience. Current tools are 
designed for system analysts and programmers. They are unable to handle 
cognitive demand to represent the knowledge the expert provides in a structured 
way so that such knowledge can be transformed into a remote operational system. 

We need a generic approach by which people who have experience can work 
on the information they want to deliver. In general, human knowledge is not well 
structured and often relies on the understanding of individuals. In order to enable 
better information transfer, a formal modelling approach provides a structure 
means of achieving these goals and simplifies the complexity of communication 
(Barkan et al, 1993). In our research, we regard the remote customer support as a 
process which can be described conveniently by an IDEF3 model as shown in 
Figure 2. IDEF stands for /CAM D^Finition methods. It results from a series of 
research carried out by the US Air Force in 1970s (Bravoco and Yadav, 1985). 
IDEF3 is one of the methods developed specifically for describing processes 
(KBSI, 1997). 

The remote customer support process is in fact a loop consisting of a series of 
dialogues with the remote customer. The system works with the knowledge base 
to provide answers according to the feedback from the customer. 



97 





User unsatisfied with result. Requests advice again. 



Figure 2 Current remote operational support processes. 



5 THE SYSTEM FRAMEWORK 



The approach provides integration of the technologies: World Wide Web (WWW), 
hypertext markup language (HTML), interactive forms, graphics, video/audio, 
artificial intelligence, supported by IDEF3 modelling methodology, object oriented 
technology, Java. The system consists of 4 blocks as shown Figure 3. 
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elements queries server browser 
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Figure 3 System framework. 

The essence of the approach is to use IDEF3 process modelling tools to 
capture the knowledge of the expert in an explicit fashion. The logistics and 
procedures of solving problems for customers are represented as a series of process 
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charts which can be easily understood by any personnel. Knowledge blocks are 
defined which include problem solvers that are not divisible but can be called up to 
provide the answers easily. Once the model is captured, the modelling tools will 
be used to convert the model into a readable format so that it can be further 
converted into the final deliverable. 

IDEF3 is an object-oriented process modelling language. Object oriented 
methods have proved very useful in many manufacturing system development 
(Basnet and Mize, 1995). In IDEF3, a process block is defined in similar way as a 
class in a computer language. When it comes to the point of inserting the process 
into an activity chain, the process block is instantiated. Hence, the same process 
can appear at different steps of the whole cycle. Moreover, attributes which are 
defined from the generic process block are inherited. For example, the process 
description, facts and constraints are automatically picked up during the 
instantiation procedure. A lot of time can then be saved due to repeated use of 
objects. 

In order to enable an interactive process model browsing and manipulation, a 
Java program is incorporated as an applet into every HTML page. The applet is 
activated by a “WEB MAP” button conveniently located on each page and 
activates the Java program on a separate window. A “model description file” is 
written by the conversion program and downloaded as part of the applet definition 
on the HTML page. The applet is downloaded and run without entry sound play 
but messages can be seen at the bottom of the Web browser. The blocks in the 
applet are active. If the pointer is inside the button boundary, the URL for that 
block is automatically displayed at the dialogue section of the applet window. 
Clicking the block will activate the Web page. 

In order to attract the user in the interface, the registration block where the 
user is reading is displayed in pink. Blocks which has further decomposition are 
coloured dark grey with an extended flag to indicate that more model blocks are 
expected at lower levels from there. Other blocks are displayed as light grey. 
Other functions such as controlled URL in the applet are also included. 



6 DIRECTORY STRUCTURE 

When the HTML structure is generated from an IDEF3 model, it is imperative to 
ensure that it knows where to find the other components of the system. In FIRST, 
this convention is handled by a pre-defined directory structure which takes care of 
general and individual company’s needs. 

The directory structure to hold the files is designed with a relative designation 
from a starting point defined by the user in his/her home page. The user can then 
create a URL from the home page to the Web pages generated by FIRST as shown 
in Figure 4. 
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• Bold types are the actual directory name 

• Normal types are changed according to requirements 



Figure 4 Directory structure to support FIRST. 

The pics/ directory has a common/ sub-directory and models/ sub-directories. 
All pictures, video, audio files are stored in this directory. The common/ sub- 
directory contains pictures, video and audio files which are common to all models. 
A typical example is the vacation.gif file which is included in all models to 
indicate the job is done. 

The models/ sub-directories contain similar types of files but are specifically 
used for that model only. If the model is removed from the server, the relevant 
sub-directory will be removed too. 

The clips/ directory contains all the executables which are activated by CGI- 
bin scripts. It also contains the common knowledge bases for all users. For 
knowledge and information specific to individual users, user sub-directories are 
created under clips/ and contain data files which will be read in by the executables. 
They are the working directories of each user session. Examples of the data files 
include .bin, .clp, .dat, .log files. Some of these files are created by the executables 
during run time. This arrangement separates the data files from individual users so 
that information can be specific to the need of individual customers. 



7 AN IMPLEMENTATION EXAMPLE 

This paper describes an industry project involving a CNC machine manufacturer. 
The industry partner has customers all over the world and hence needs to provide 
effective and responsive remote support to customers in the use, maintenance and 
troubleshooting of their equipment. As the market for CNC machines expands. 
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these needs will increase extensively in the next few years so that the current 
support processes will no longer be economically viable. In addition, the company 
desires to capture the vast expert knowledge within and outside the company 
concerning their CNC machines, especially as it pertains to problem diagnosis. 
However, there is no ready means of gathering and storing this knowledge, and 
hence no way to exploit it for remote customer support. 

From these observations, the framework for creating the remote customer 
support system is built around a knowledge repository consisting of field and 
engineering knowledge of the industry partner and their customers, as shown in the 
system architecture in Figure 5. Four user interfaces. Remote Machine 
Diagnostics, Remote Process Optimisation, Remote Knowledge Acquisition and 
Remote Operator Training, which interact with the user at a remote location, 
interrogate the Knowledge Repository to provide appropriate information to the 
user. In this way, all functions can be kept up-to-date easily through the latest 
network technologies. 




Figure 5 Current process of remote operational support systems. 

The creation of the system started from the IDEF3 model screen as shown in 
Figure 3. Process blocks are defined using the modelling software so that the 
creator can have a true “MAP” of the customer support process. 
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8 CONCLUSION 



A framework has been presented in this paper to address the issue of flexibility and 
effective remote customer operations support. The approach starts with the use of 
IDEF3 process modelling methodology to describe the series of activities that a 
remote operator may interact with the expert engineers back in the supplier 
company. The model is created using a commercial IDEF3 software which 
provides easy manipulation of model and user friendliness. The resulting model is 
then transformed into a structure of HTML pages by a conversion program 
developed by CSIRO. 

The essence of this approach is to eliminate the difficulties that normal 
service and support engineers need to handle to create systems in complex 
operations and service knowledge. The framework provides methods of defining 
the elements, including multimedia components into the model and subsequently 
generated automatically. This characteristics simplifies the work of engineers 
significantly and hence helps engineers to develop systems which are more 
relevant to the customer’s needs. 

The framework has been applied to allow engineers of a CNC manufacturer 
to generate their own supporting information system. Further development of the 
system has been planned within the Globeman 21 partner’s community. It is 
anticipated that the system will be bundled with the CNC manufacturer’s product 
in the future. 
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Abstract 

There are a number of different approaches to information infrastructures, all of 
which purport to be an answer to the problem of integrating diverse heterogeneous 
systems. Frameworks and Reference Models are also used for similar purposes. 
Each has a slightly different focus and approach, yet all are essentially addressing 
the same problem. Several reference models have been proposed and information 
infrastructure systems are under development for shop floor control in the discrete 
manufacturing and semiconductor industries, for high level distributed interactive 
simulations, software engineering and for collaborative design and manufacturing. 
In this paper we review several of the current approaches and develop a reference 
architecture which is then used to categorize and compare these same approaches. 
Approaches and models reviewed include the ADAPTIVE Communication 
Environment (ACE), the Common Object Request Broker Architecture/Common 
Object Services Specification (CORBA/COSS), the Distributed Computing 
Environment (DCE), the High Level Architecture (HLA), the Simulation-Based 
Design (SBD) architecture, the National Industrial Information Infrastructure 
Protocols (NIIIP), Shipbuilding Information Infrastructure Project (SHIIP), and the 
Systems Integration Architecture (SI A). A brief description of the proposed 
reference architecture and of each system is given and the services it provides are 
compared with those in the reference architecture. 

Keywords 

Collaboration, Framework, Reference Model, Information Infrastructure 




1 INTRODUCTION 



The proliferation of personal computers and desktop workstations with the 
advances in technology and the tremendous growth of networking and 
internetworking with the availability of plenty of bandwidth has changed the role 
of computing in institutions of all forms. Whether for business, educational, or 
cultural purposes, organizations are seeking to maximize their effectiveness by 
allowing the information needed to manage and run operations to be created, 
maintained, and disseminated over a growing base of interconnected desktop 
computers, instead of building on host-based centralized computing roots. 
Distributed information is the catalyst enabling organizational and business- 
process restructuring to be done at unprecedented speeds [14]. 

To lower costs, get products to market faster, and respond to changing market 
conditions, many organizations have turned to a flexible form of computing called 
client/server computing that supports the use of desktop computers as clients 
accessing information from various backend servers. The migration from 
mainframes to client/server computing has resulted largely from the emergence of 
the widespread use of personal computers and software, several standard graphical 
user interfaces, better networking, and increasingly capable and inexpensive 
servers. 

Companies involved in intense global competition have begun flattening their 
organizations to avoid unnecessary layers of hierarchy. With the use of 
decentralized computing resources, management is able to give users more 
authority for local decision making, eliminate bureaucratic positions, and tap into 
the innovative talents of more members of the organization. Early developments of 
groupware like e-mail and conferencing with the wider use of advanced 
communication and client/server technologies is facilitating the evolution of 
collaborative computing that makes seamless semantic level interaction possible 
among users on heterogeneous systems. 

With the need and wide spread acceptance of collaborative computing, various 
collaboration frameworks have been proposed by industry and academia. The 
purpose of this survey is to understand some of these frameworks and propose a 
general framework of collaboration that could be used to compare the features and 
capabilities of these frameworks. In this paper we focus on general comparison of 
individual frameworks features. The following frameworks have been explored: 

• ADAPTIVE Communication Environment (ACE) [12] 

• Common Object Request Broker Architecture/Common Object Services 
Specification (CORBA/COSS) [7, 13] 

• Distributed Computing Environment (DCE) [2] 

• High Level Architecture (HLA) [4] 

• National Industrial Information Infrastructure Protocols (NIIIP) [3, 6] 

• Simulation Based Design (SBD) [10] 

• Shipbuilding Information Infrastructure Protocols (SHIIP) [11] 

• Systems Integration Architecture (SIA) [5] 
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2 FRAMEWORK FOR INTEGRATION 



2. 1 Framework versus Architecture 

The general collaboration framework that is proposed in this paper is synthesized 
from the common features of a multitude of frameworks or infrastructures under 
construction or in use by industry and academia. Some of the common 
technological features are: 

• Client/Server Technology 

• Object orientation, Object wrappers 

• Components, Distributed Objects 

• Component Frameworks 

• Collaboration Bus 

• High Level Frameworks for Collaboration 

A framework or an architecture is a high-level description of the organization of 
functional responsibilities within a system. The goal of an architecture or 
framework is to convey information about the general structure of systems. 
Although there is no single, all encompassing architecture for computing, before 
developing collaborative applications, two architectures should be devised. These 
are a technical architecture and an information architecture [1]. 

A technical architecture provides a blueprint for assembling technology 
components. A technical architecture defines what tools and technologies will be 
used and how they will be used. This may include the definition of objects that 
encapsulate several databases, middleware and other technologies, as well as 
which development tools to use and how they will be integrated to provide a 
complete software project support environment. 

An information architecture describes content, behavior, and interaction of 
business objects. These concepts build a semantically rich model of the problem 
domain. The information architecture prescribes the building blocks for application 
development. Business objects use the services of the technical architecture 
objects. An information architecture provides a framework for the information 
components of the business, e.g., subjects, events, roles, associations, business 
rules etc. 

In the general reference framework for collaboration shown in figure 1 , the 
collaboration bus and all the layers below that form the technical architecture. All 
the layers above the collaboration bus form the information architecture. 
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2.2 



The General Reference Framework for Collaboration 



Figure 1 shows a general reference framework for building a collaborative 
infrastructure. This general framework is synthesized from the common features of 
various collaboration frameworks. Hardware, operating system, legacy and simple 
non-collaborative applications including various system utilities form the 
computing system to be integrated into a collaborative environment. The hardware 
includes computing (CPUs), communication (wireless, wired), and data 
storage/retrieval (electrical, magnetic, and optical) hardware. Traditional remote 
procedure call (RPC) based mechanisms or object wrappers can be used to provide 
a dynamically reconfigurable computing system interface to upper layers of a 
collaboration framework. In fact, the system-level frameworks provide an 
organized environment for using a collection of objects that reside on the local 
computing system. System-level frameworks offer simple patterns that guide the 
collaboration of objects on the local computing system to provide the system 
specific services requested through the collaboration bus. 




Figure 1 : General Reference Framework for Collaboration 

The collaboration bus is the backbone for building a collaborative infrastructure. It 
provides interoperability among software components residing on various 
computing systems. General collaboration frameworks are the collection of tools 
and components that use the distributed services provided through the 
collaboration bus to provide semantic-level interactions among distributed 
software components. High-level collaboration frameworks are more specialized 
collaboration frameworks that are designed to achieve specific business objectives. 
Typically a user in a collaborative environment interacts with other users and 
distributed information resources via a user interface. All these user interactions 
generated through the user interface are constrained by the high-level business 
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objectives. The actual semantics of interactions are resolved and put into action by 
the general collaboration frameworks by discovering the necessary software 
components via the collaboration bus. 

The types of services provided by the System-level Frameworks include naming, 
event, time, and so on. At the General Collaboration Frameworks level, higher- 
level services are provided that are domain-independent, such as user interface. 
Finally at the High-level Collaboration Frameworks level, domain-specific services 
are provided for each application domain such as accounting, simulation, 
manufacturing, and so on. We will be using this general framework of figure 1 to 
assess, categorize, and compare some of the frameworks published so far. 

3 Technical Frameworks 

The following technical frameworks or architectures are discussed in this section. 

• ADAPTIVE Communication Environment (ACE) 

• Common Object Request Broker Architecture/Common Object Services 
Specification (CORBA/COSS) 

• Distributed Computing Environment (DCE) 

3 . 1 ADAPTIVE Communication Environment (ACE) 

A Dynamically Assembled Protocol Transformation, Integration, and evaluation 
Environment (ADAPTIVE) Communication Environment (ACE) is a high-level 
C++ toolkit for writing sophisticated concurrent, parallel, and distributed 
applications. ACE is an object-oriented network programming toolkit for 
developing computer communication software. 

ACE provides a standard library of distributed services that are packaged as self- 
contained components. These reusable components provide distributed system 
services like naming, event routing, logging, time synchronization, and network 
locking. The common communication software capabilities of ACE include [12]: 

• event demultiplexing and event handler dispatching, 

• service initialization, 

• interprocess communication, 

• shared memory management, 

• message routing, 

• dynamic (re)configuration of distributed services, 

• concurrent execution and synchronization. 

3.1.1 ACE and General Reference Framework for Collaboration 

ACE provides a rich set of reusable C++ wrappers and framework components that 
perform common communication software tasks across a range of operating 
system platforms. So ACE provides the object wrappers and some system-level 
frameworks, mainly dealing with communications, in the General Reference 
Framework shown in figure 1. These are eventually used to build a collaboration 
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bus. Specifically, ACE has been used to build a real-time implementation of 
CORBA called TAG. 

3.2 Common Object Request Broker Architecture/ Common Object 
Services Specification (CORBA/COSS) 

Figure 2 shows OMG's Object Management Architecture. CORBA/COSS refers to 
Object Request Broker and Common Object Services in the architecture. The 
bottom 4 levels in figure 2 provide domain-independent services, whereas the top 2 
levels (Vertical Market Facilities, Collaborative Applications) are domain specific. 

3.2. 1 Object Request Broker 

The Object Request Brokers [7] provide the basic communication channel through 
which objects on various systems interact. ORBs enable objects to transparently 
make and receive requests and responses in a distributed environment. It is the 
foundation for building applications from distributed objects and for 
interoperability between applications in hetero- and homogeneous environments. 




Figure 2: OMG’s Object Management Architecture 
3.2.2 Common Object Services 

Common Object Services are a collection of services (interfaces and objects) that 
support basic functions for using and implementing objects. They are collections of 
system-level services packaged as components with IDL-specified interfaces. They 
represent the essential interfaces needed to create an object, introduce it into its 
environment, use and modify its features, and so forth. OMG has currently defined 
standards for fifteen object services which are naming, event, life cycle, persistent 
object, transaction, concurrency control, relationship, externalization, query, 
licensing, property, time, security, object trader and collection services [7, 8]. 
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3.2.3 CORBA/COSS and General Reference Framework for 
Collaboration 

With respect to the General Reference Framework in figure 1, CORBA/COSS 
provides object wrappers or object adapters, distributed objects or components, 
many system-level frameworks and the collaboration bus. . Furthermore, OMA's 
horizontal common facilities provide the necessary building blocks to build general 
collaboration frameworks. The vertical market facilities are the high-level or 
specialized collaboration frameworks for specific domain. 

3.3 Distributed Computing Environment (DCE) 

The Open Group's Distributed Computing Environment (DCE) [2, 9] is a suite of 
integrated software services that is part of a computing system's infrastructure and 
enables the development of distributed applications across heterogeneous systems. 
To support the development of distributed applications DCE provides the 
following key distributed services like Remote Procedure Call, Security service. 
Cell and Global Directory Services, Threads service, Distributed Time Service, and 
Distributed File Service. 
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Figure 3: DCE Architectural Framework 

Figure 3 shows the DCE architectural framework and components. It is designed 
to be independent of hardware, operating systems, and networks, allowing DCE 
distributed applications to run on a wide variety of computers simultaneously. 
Communication transparency is incorporated into the infrastructure for the RPC. 
Network security and locating distributed resources are solved by security and 
directory services. Threads service enable RPC servers to handle multiple requests 
concurrently. 
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3.3.1 DCE components 



The functionality of the components in the DCE architectural framework in Figure 

3 can be summarized as follows: 

• Remote Procedure Call (RPC) - mechanism by which clients invoke 
procedures in servers. The RPC mechanism insulates clients from details of 
where servers are located on the network, the types of hardware and operating 
system platforms on which they execute, differences in data representations 
between client and server platforms, and the particular network transports in 
use. 

• Directory Services - support local DCE administration domains called cells 
and inter-cell name resolution. 

• Security Services - support authentication, authorization, and privacy. 

• Distributed Time Services (DTS) - synchronize all clocks in a DCE cell, as 
well as between cells. 

• Threads Service - supports the creation and management of multiple threads of 
control within a client or server. 

• Distributed File Service - provides a uniform namespace, and file location 
transparency. 

3.3.2 DCE and General Reference Framework for Collaboration 

With respect to the General Reference Framework, some system-level frameworks 

and the collaboration bus are what DCE provides. 



4 TECHNICAL FRAMEWORKS 

The following information frameworks or architectures are discussed in this 
section. 

• High Level Architecture (HLA) 

• National Industrial Information Infrastructure Protocols (NIIIP) 

• Shipbuilding Information Infrastructure Project (SHIIP) 

• Simulation Based Design (SBD) 

• Systems Integration Architecture (SIA) 

4. 1 High Level Architecture (HLA) 

The Department of Defense (DoD) Modeling and Simulation Master Plan defines 
the objective of developing a Common Technical Framework for Modeling and 
Simulation. The Common Technical Framework [4] consists of three components 
for simulation development and interaction: the High Level Architecture (HLA), 
Conceptual Model of the Mission Space (CMMS), and Data Sandardization (DS). 
Among the three components HLA is the highest priority. 
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4.1.1 Overview of HL A 

The fundamental goal of HLA is to establish a common high-level architecture to 
facilitate the interoperability of all types of models and simulations among 
themselves and with C4I systems as well as to facilitate the reuse of Modeling and 
Simulation (M&S) components. The HLA federation is the set of HLA-compliant 
interoperating simulations. A simulation that is a member of a HLA federation is 
called a federate. Figure 4 illustrates the functional view of the HLA. HLA is 
defined by the following components [4]: 

• HLA rules - A set of rules which must be followed to achieve proper 
interaction of simulations in a federation. These rules describe and cleanly 
separate the responsibilities that are placed on both the federates and on the 
runtime infrastructure (RTI). The RTI is a set of software components that 
implement the services specified by the HLA Interface Specification. The RTI 
provides the common interface services for the execution of an HLA 
federation. 

• Interface Specification - The set of HLA interfaces that provide each of the 

services between the RTI and a federate. These services are organized into the 
following distributed simulation management categories: Federation 

Management, Object Management, Time Management, Declaration 
Management, Ownership Management, and Data Distribution Management. 

• Object Model Template - The prescribed common method for recording the 
information contained in the required HLA Object Model for each federate 
and federation. Each federate is required to define its own Simulation Object 
Model (SOM). The SOM defines the kinds of interaction messages that the 
simulation is capable of sending or receiving. Each federation is required to 
define its particular Federation Object Model (FOM) which standardize the 
way objects are represented between the federates, what their attributes are, 
and the kinds of interactions that will be supported between federates. 

4.1.2 HLA and General Reference Framework for Collaboration 

HLA provides the high level collaboration frameworks for the simulation domain 
in the General Reference Framework for Collaboration shown in figure 1 . HLA is 
a modeling and simulation vertical market facility in the OMG's Object 
Management Architecture shown in figure 2. HLA can be used by simulation 
system developers and policy makers because it provides a systematic and 
consistent basis for addressing simulation system design and implementation issues 
in a collaborative environment. 

4.2 National Industrial Information Infrastructure Protocols (NIIIP) 

National Industrial Information Infrastructure Protocols (NIIIP) [6] are being 
developed by a consortium of 18 organizations to enable Virtual Enterprises (VE) 
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to collaborate and share engineering and manufacturing information. NIIIP defines 
a virtual enterprise as a temporary consortium of organizations, often crossing 
company boundaries, that come together to exploit fast-changing opportunities. 
The NIIIP consortium is developing a reference architecture and reference 
implementation for the technologies needed from industrial Virtual Enterprises. 
Basically it seeks to satisfy the information needs of the Virtual Enterprise by 
integrating and building upon the work of a number of selected standards. It 
consolidates, harmonizes, integrates, and extends existing protocols. 
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Figure 5: NIIIP Reference Architecture 
4.2. 1 NIIIP Reference Architecture 

Figure 5 shows NIIIP Reference Architecture. At the highest level, there are four 
technology requirements for industrial Virtual Enterprises [6]: 

• Common communication protocols 

• Uniform object technology for system and application interoperability 

• Common information model specification and exchange 

• Cooperative management of integrated Virtual Enterprise processes 

NIIIP consortium uses core technologies such as: Internet and related 
communications facilities and services; Object Management Group (OMG) and 
related object technologies; and Standard for the Exchange of Product Model Data 
(STEP) and related information modeling technologies. Since these core 
technologies are not yet well integrated, NIIIP focuses on extending and 
integrating these technologies to enable cooperative work. 
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Figure 6: NIIIP Components 

As shown in figure 6, the NIIIP architecture currently defines 13 components 

(shown in ovals in figure 6) and these in turn are grouped into five subsystems. 

The components of the NIIIP architecture are candidates for Common Facilities 

within OMG's architecture. 

4.2.2 NIIIP components 

The 13 NIIIP components are services needed to create and manage industrial 

Virtual Enterprises and can be summarize as follows: [3] 

• Desktop - Human interface to multiple VEs and VE resources; VE 

administration 

• Access - CORBA and non-CORBA mediated object access; replication, 
caching; interface to DFS, SHTTP, TCP/IP disguised initially as a CORBA 
request but then "trapped out" (intercepted) 

• Agent - Non-human interface to VE organizational structures, resource 

ownership, settlement; "proxy objects" acting as transducers 

• STEP Services - Behaviors to support the STEP Data Access Interface (SDAI) 

• Data Management - Shared data management; change management; 
configuration management; View/schema/encryption translations between 
source and target 

• Workflow - Cross-product workflow management 

• Session - Authentication, uses, context (tasks and sessions), resource 

allocation, transaction logging; simulation; long transaction control 



115 






• Application - Application invocation setup; moving data to application, 
application to data 

• Mediator - Resolving semantic ambiguity; summarizing, abstracting, 
validating data; localized knowledge; maintenance of local ontologies; data 
translation between source and target application objects 

• Negotiator - Manage multi-party negotiations impartially 

• VE KBMS - Active semantic network database for VE 

• Internet Tools - Access to the services of the Internet; conferencing, WWW, 
control point for the secure VE 

• VE Monitor - Generate before and after method bindings to NIIIP protocol 
anchor and end-user application objects 

4.2.3 NIIIP and General Reference Framework for Collaboration 

With respect to the General Reference Framework for Collaboration, NIIIP 
provides general collaboration frameworks and high-level collaboration 
frameworks for the Virtual Enterprise domain. 

4.3 Simulation Based Design (SBD) 

Simulation Based Design [10] is an open, multi-agent, distributed, collaborative, 
virtual development environment aimed at revolutionizing the acquisition and 
support of complex systems throughout their entire life cycle. SBD is a technology 
component of DARPA's Simulation Based Acquisition (SBA) Program. SBD 
provides geographically distributed enterprises with a synthetic environment for 
planning, developing and optimizing a product through Collaborative Virtual 
Prototyping (CVP). SBD supports multiple virtual products operating in physics 
based synthetic environments and their Multi-Disciplinary Analysis (MDA) and 
Multi-Disciplinary Optimization (MDO) via a detailed Smart Product Model 
(SPM) stored in a database. SBD uses HLA and CORB A as its interface standards. 

SBD can be seen as a common database, consisting of smart product model, 
smart product catalog and simulations, surrounded by various tools like 
requirement tools, legacy engineering tools, workflow tools, commercial tools 
(CAD etc.), 3D visualization tools, cost tools etc. A layered architecture for SBD is 
shown in figure 7. 

4.3.1 SBD Architecture 

The layered architecture for SBD shown in figure 7 hides details of the underlying 
hardware and network by supporting a collection of higher level agents which 
provide direct, broad based support for the generic user. Related agents are 
grouped into user services, reflecting the principal capabilities which will be 
supported by the SBD system. The user services are [10]: 

• Data Services - deal with product and process representation and 
manipulation. It uses an object oriented approach to modeling data, allowing 
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component descriptions and behaviors to be linked in an active system called 
the Smart Product Model (SPM). 

• Integration Services - support collaboration and interoperation of tools. It 
includes a shared electronic notebook for human communication and systems 
for assembling collections of tools into integrated megaprograms. 

• Interaction Services - provide advanced visualization, immersive and 
collaborative means for spatially manipulating products and processes. It also 
provides for operator-in-the-loop simulation. 

• Application Services - manage the more or less static (mostly Commercial Off 
The Shelf (COTS)) applications which perform specific roles for SBD users. 

Individual services are comprised of multiple agents, and agents across the 
system communicate and interoperate in very flexible ways. The intelligent 
information bus is the underlying layered structure below the user services. Its 
major role is to support the communications needs of the higher level agents. This 
bus comprises three main components [10]: 




INTELLIGENT INFORMATION BUS 



Figure 7: Simulation Based Design Architecture 

• Information Sharing layer - is concerned with the higher level 
communications needs between entities in the system. It supports notions such 
as publication and subscription of interest in specific objects, attributes, or 
events. 

• Object Management layer - hides the complexity of communication in a 
distributed, heterogeneous computing environment from users and 
applications. 

• High Performance Computing and Communications (HPCC) network 
interface layer - isolates details of the underlying hardware and 
communications at the network level from the Object Management Layer 
and other, higher level agents. 
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4.3.2 SBD and General Reference Framework for Collaboration 



SBD provides the collaboration bus, general collaboration framework, and a high 
level collaboration framework for CVP in the general reference framework for 
collaboration shown in figure 1. SBD is a vertical market facility for CVP in the 
OMG's object management architecture. 

4.4 Shipbuilding Information Infrastructure Project (SHIIP) 

The goal of the SHIIP project is to develop, deploy and standardize a new 
shipbuilding methodology for the US shipbuilding industry [11]. The advanced 
information infrastructure comprises the component of the new shipbuilding 
methodology. The goal of the SHIIP information infrastructure is to deliver 
enterprise- wide information to the shipbuilding work force. 
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Figure 8: SHIIP Reference Architecture 
4.4. 1 SHIIP Reference Architecture 

The SHIIP Reference Architecture follows the lead of the NIIIP architecture in that 
it seeks to satisfy the information needs of the shipbuilding enterprise by 
integrating and building upon the work of a number of selected standards. These 
standards include the Object Management Group (OMG) for distributed object 
technology; the Internet Standards (including the WWW standards such as HTML 
and VRML) for communications; the STEP standards for product information 
sharing; and the Workflow Management Coalition standards for workflow. 

Figure 8 shows SHIIP reference architecture at the top level. The SHIIP 
reference architecture contains a subset of the Components Objects from the NIIIP 
reference architecture. This subset consists of services selected based on their low- 
risk nature and applicability to the needs of the shipbuilding enterprise. The 
Workflow, Task/Session, and STEP services have been substantially defined and 
prototyped within the NIIIP project and will be deployed in the SHIIP project. The 
Desktop, Agent, and Data Management Components will be specialized from the 
NIIIP protocols to suit shipbuilding requirement. The Business Objects (and 
associated Mediator) represent a deployment of work under way within OMG in its 
Business Object Domain Task Force. These objects have not been explicitly 
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specified in the NIIIP protocols but are interoperable with the NIIIP objects 
through the CORE A framework. 

4.4.2 SHIIP and General Reference Framework for Collaboration 

With respect to the General Reference Framework for Collaboration, SHIIP 
provides general collaboration frameworks and high-level collaboration 
frameworks for the ship building application domain. 

4.5 Systems Integration Architecture (SIA) 

Systems Integration Architecture (SIA) [5], developed at the Agile Aerospace 
Manufacturing Research Center (AAMRC) of the Automation & Robotics 
Research Institute, is an agile information infrastructure that integrates legacy 
systems and provides a basis model to build virtual enterprises. The basis model 
for SIA is a functional programming approach to systems development. It is based 
on the concept that all information processing is a series of transformations of data 
sets called aspects. The transformations are done by modules called Functional 
Transformation Agents (FTAs). FT As are considered as black boxes whose interior 
can be developed using any software or hardware. 

Figure 9 shows a high level block diagram of SIA. The architecture has three 
modules to provide the necessary services to create and control FTAs and aspects 
in a heterogeneous distributed environment. The three modules are [5]: 

• Executive Module - provides the front end of SIA using a GUI. It makes all the 
necessary communications required in a distributed environment transparent to 
the user. It uses the communications module to achieve this transparency. 
Executive module essentially controls the user access to the system and its 
resources. It allows any degree of business control from a workflow 
management approach. The executive can start, stop, and pause/resume 
processes as well as request status information. 

• Librarian Module - is the central module in SIA. It is a kind of meta data 
dictionary whose basic function is to manage the references and associations 
among users, processes, applications, and data sets, and to maintain 
information about the existence and format of all data in the system. 

• Communications Module - now uses COREA as the reference architecture to 
create a heterogeneous and distributed communications interface. The 
executive module and the librarian use this communication interface via high 
level network services to make the network communications transparent to the 
end user. 

• Function (or Launcher) Module - allows users to launch local/remote 
applications using local/remote data sets, while using a local user interface. 
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4.5.1 SIA and General Reference Framework for Collaboration 



With respect to the General Reference Framework for Collaboration, SIA provides 
general collaboration framework which facilitates the development of high-level 
collaboration frameworks. For instance, Aeroweh which is a high-level 
collaboration framework for supply-chain management has been developed on top 
of SIA. 
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Figure 9: Systems Integration Architecture 



5 CONCLUSIONS 

We have overviewed 8 existing frameworks and categorized the existing 
collaboration frameworks into technical and information frameworks. We also 
proposed a general reference framework for collaboration and used it to compare 
the features and capabilities of those frameworks. Figure 10 illustrates the features 
and capabilities of those frameworks. 

CORE A/COS S and DCE are the basic technical frameworks for building a 
heterogeneous distributed system. Since these are meant to be standards and 
specific implementations from various vendors are available. ACE provides a 
reconfigurable framework for basic network services required to build a distributed 
system. ACE is used to build a real time COREA implementation called TAO. 

Most of the information frameworks explored use COREA/COS S to provide 
collaboration bus. HLA is a high priority effort by DMSO to facilitate all types of 
DoD simulations. Since HLA provides an object oriented information framework 
for simulations, it may be standardized to be a vertical market facility for 
simulations by OMG. DARPA's SED is a robust framework for collaborative and 
distributed design. SHIIP seems to be the first and largest industry effort to use the 
existing technological base and new standards like NIIIP, HLA, SED, and 
CORE A/COS S to build an enterprise wide collaborative virtual prototyping 
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system. SIA provides flexible general collaboration framework to facilitate the 
rapid development of high-level collaboration frameworks on top of it. We also 
have to mention that there are other collaboration frameworks which are being 
developed, but not covered in this paper due to space limitation. 
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Abstract 

Business processes are frequently becoming distributed processes. This is due to 
the emergence of global markets and global manufacturing made possible by 
improved communications and support from ERP systems. 

Optimization of business processes requires tuning of the process and application 
layers, and of the process and infrastructure layers. This requires insight into the 
consequences of decisions at one layer for another layer. Automated tools for 
analysis are expected to play an important role in the support of decision making 
during ERP implementations for distributed businesses. 

The present paper covers the DIAMond project, its method, cases studied and 
intermediate results. 



Keywords 

Modelling of distributed processes, applications and infrastructure, analysis tools, 
performance indicators. 




1 INTRODUCTION 



The 1990's mark the first decade when companies around the world have to start 
thinking globally to remain competitive. Time and distance have been rapidly 
shrinking with the advent of faster communication, transportation, and financial 
flows. Companies that are able to exploit these developments can put themselves 
in a position of decisive competitive advantage. In particular, the increased 
technical opportunities can be exploited to efficiently stretch the realm of 
integrated logistic control beyond the borders of the individual company and 
support so-called extended or even virtual enterprises (Kotler, 1991). But to realize 
this, more is needed than the state-of-the-art in infrastructure, per se, can offer. In 
particular, the information systems that support integrated logistic control, such as 
Enterprise Resource Planning software, should be inherently suited for a 
distributed environment. 

Implementation of ERP systems in globally distributed companies shows that 
this type of information system is still too much designed with geographically 
centralized companies in mind. For ERP suppliers it is a challenge to gear their 
products more towards a distributed context. More options concerning distribution 
in space and time should be available. But a higher degree of flexibility in 
distribution of the ERP system also implies that more sophisticated support is 
needed to select at least a satisfactory allocation from a nearly infinite number of 
choices, during the implementation. Which allocation is chosen depends on the 
business requirements and the constraints concerning the application and the 
infrastructure in that particular situation. The objectives and constraints at these 
three levels are strongly interrelated (see Figure 1) which make the implementation 
far from straightforward. 

The complexity of allocation selection described above led to the start of the 
DIAMond (Distributed Infrastructure and Applications Modelling) research 
project. The DIAMond project is supported by the Dutch Ministry of Economic 
Affairs, and is carried out by the Eindhoven University of Technology in co- 
operation with Baan Research & Development, Philips Consumer 
Communications, Baan Institute and Origin International B.V. 

The goal of the DIAMond project is the development of methods, techniques 
and tools by which an enterprise can be modelled, such that insight can be gained 
into the performance of a multi-site ERP system and such that an optimal 
allocation of resources can take place. 

Some of the questions are: 

• Which entities are relevant in a model of a distributed application and 
infrastructure and what are their relevant attributes? 

• What constitutes the performance of an allocation and how can it be 
quantified? 

• What relations exist between allocations and their performance? 

• What properties does a modeling syntax need to have to be able to describe the 
entities mentioned above and their distribution? 
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In its approach, the DIAMond project addresses methodology by looking at 
how the reference architectures of ENV 40003 and ARIS can be used to model 
distributed businesses, and how they can serve the expression of model 
alternatives, and the assessment of performance characteristics. An interesting 
aspect is that settings can be done at different modeling layers of the reference 
architectures as distinguished in Figure 1 and that performance characteristics will 
appear on the other layers. The methodology is then applied to a case to identify 
performance parameters and indicators and mechanisms to calculate with them. 




Figure 1 Layers between business requirements and technical 
constraints. 



The DIAMond approach differs in focus from that taken in projects such as 
PRODNET II, VEGA and NIIIP, which are also concerned with distributed 
infrastructures. The emphasis in DIAMond lies on the modeling of distributed 
infrastructures and the applications using them in support of design and 
development, and not on building or developing such an infrastructure and making 
it available. For instance, the objective of the NIIIP (National Industrial 
Information Infrastructure Protocols) project is to foster the development of 
technology enabling industrial virtual enterprises and the adoption of STEP in such 
enterprises. The NIIIP goal is to develop, demonstrate and transfer into wide 
spread use the technology to enable industrial virtual enterprises. The PRODNET 
(Production Planning and Management in an Extended Enterprise) effort is aimed 
at the design and development of an open platform and adequate IT protocols and 
mechanisms to support virtual enterprises, in particular those involving small and 
medium size enterprises. VEGA (Virtual Enterprises using Groupware Tools and 
distributed Architectures) is aimed at creating a software architecture that will 
support the exchange of project and product information in a virtual enterprise. The 
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DIAMond project aims at providing primitives (and the methodology to use them) 
for modeling an (extended, virtual or regular) enterprise, and its business 
processes. The resulting enterprise model is capable of expressing particular 
performance aspects for various distributed designs for a given business process 
and this way supports a well-founded choice (with respect to infrastructure and 
applications) for its implementation in a distributed environment. The issue here is 
not how to provide a common platform or infrastructure, but how to allocate the 
various system components (hardware and software) to get suitable IT support for 
the business process. 

In the remainder of this paper we will first discuss a case to provide some 
context for the distribution issues we wish to model. Then we give some 
background on the methodology used. This provides the necessary knowledge for 
the discussion of the questions cited above. 



2 THE EM CASE 

In this section the case of an electronics manufacturer (EM) will be introduced. In 
the next sections specific elements from this case will return for the purpose of 
illustration. 

A large manufacturer of mobile telephones has a Central Sales Office for its 
European market (CS 0/Europe). The manufacturer controls several warehouses 
around Europe and has three production sites on as many continents. The 
production of mobile phones takes place in two phases. In the manufacturing 
phase transceivers are produced that are suitable for all types of phones. The 
second phase is the distribution phase in which the phone is assembled. In this 
phase the transceiver is put in a case with a certain color, imprinting, logo and so 
on. After the distribution phase the products go to one of the warehouses. Diversity 
of the end products is high, with more than 400 models in the production range. 

The CSO accepts orders from customers and from salesmen or sales offices. 
When an order comes in, the nearest warehouse is checked to see if the requested 
product is in stock there. When this is not the case, the CSO checks the production 
sites by means of an Available to Promise (ATP)-check, starting with the 
production sites that are near the customer. The Available to Promise check 
indicates which part of the planned production is still not reserved for specific 
orders. The ATP-check results in a delivery date that the CSO sends to the 
customer or salesmen/sales office. Depending on the delivery date the customer or 
salesman will place the order or not. When this happens, the ATP-number is 
adjusted; there is less available to promise. Naturally it is undesirable that a second 
customer or sales person performs an ATP-check before the first one places his 
order, based on the same ATP-number. That would easily lead to over sales. On 
the other hand, it is not wise to reserve already planned production based on an 
initial check only. 

The sales volume of mobile phones for this company requires millions of ATP 
checks a year. On average an ATP-check has to be performed every three seconds. 
Each ATP-check generates a lot of communication. The problem that arises is that 
several ATP-checks are made at the same production site at the same time. To 
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prevent this, unrealistic demands have to be made to the LAN, to the WAN, to 
processing times, processing capacities, etc. The current state of affairs is that the 
order acceptance process is too slow. 



3 METHODOLOGY 

The background for our approach is based on the analogy between the model 
layers in the ENV 40003 (CEN/Cenelec, 1990; Amice, 1993) framework 
(requirements, design and implementation) and the three layers linking business 
requirements, operating principles, and technical constraints and costs (Figure 1). 
The three model levels aid the enterprise modeler in structuring the modeling work 
(ENV 12204, CEN/Cenelec, 1995): 

Requirements Model Level. At this level, one identifies the business 
requirements of the enterprise, using a business terminology, in terms of enterprise 
operations, but without reference to implementation options or decisions. 
Characteristic aspects of the business such as the global structure of its production 
process (which is split in two phases in the EM case) are given. The model is 
expressed in such a way that it can be used as a starting point for a consistent 
stepwise derivation of a design level model, and such that it can be processed for 
transformation and analysis of conformance and other criteria. 

Design Model Level. At this level one specifies how the enterprise operations 
are to be performed, that is the actions and processes that are to be performed to 
achieve the requirements. An example is the ordering process in the EM case. It 
reflects the design phase of the specifications of the enterprise model, which meet 
the requirements of the enterprise. Constructs at this level model elements that are 
the concern of the design modeler and system designer from both a business and IT 
viewpoint. At the design model level constructs are derived from those of the 
requirements model level. They are then enriched with attributes that reflect 
general IT interfaces, such that the model can be used as a starting point for a 
consistent stepwise derivation of an implementation level model, and such that it 
can be processed for transformation and analysis of conformance and other criteria. 

Implementation Model Level. Here one describes the means of execution — 
by selecting the real Information Technology and Manufacturing Technology 
Components such as human resources, machines and programs — and/or rules to be 
used in executing the enterprise operations as described at the Requirements Model 
Level. It reflects the implementation phase of the enterprise model, which meets 
the requirements of the enterprise. At this level the communication volume and 
response times and such come into the picture. 

With respect to the dimensions of the generation of views, we feel more 
comfortable with those proposed in the ARIS approach (Scheer, 1994) (see figure 
2). The views that ARIS uses to reduce the complexity of enterprise modeling 
differ from those in ENV 40003 (organization, resource, function, and 
information). The ARIS views are function view (formed by the functions to be 
performed and their relationships), data view (formed by conditions (customer 
status, article status) and events (customer order received, completion notice 
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received)), and organization view (formed by the structure and relationships 
between users and organizational units). The elements of these views are then 
linked to each other in the control view, which integrates the design results. The 
three views together with the links between them form a business model. The 
function, data and organization view present a view of the business model at the 
meta- (type) level. In the control view, the consideration of instances (occurrences) 
can be included as well. 




generic > partial > particular 

Figure 2 ENV 40 003 and ARIS, 



Baan’s Dynamic Enterprise Modeler also uses these views, but in addition 
utilizes a third dimension of the ENV 40003 framework, i.e. the concept of 
reference models (along the axis from generic, over partial to particular models). 



4 DISTRIBUTION IN SPACE AND TIME 

The views and the links between them are given a role in addressing distribution. 
Traditionally, models at the requirements (Figure 2) or business model level 
(Figure 1) only focus on types irrespective of distribution choices. Distribution 
would only be considered to matter for the design and implementation description. 
As businesses have become distributed themselves it is important to lift the 
visibility of distribution to the requirements/business model level. 
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Distribution in space is concerned with the allocation of data types, function 
types and organization unit types to sites. 

Distribution in time is concerned with the degree of synchronization required 
for functions. Synchronous execution is natural in a centralized system. 
Asynchronous execution is natural in a distributed system. 

Distribution and Organization View 

In the modeling case of a single site, the organization view will discern different 
units. For the case of a multiple site business process, we can use the concept of 
organization unit to represent the sites (or their units). A site can also represent one 
of the companies in the distributed enterprise. For instance, in the EM case, there 
are sites for General Management, Development, Central Sales Office and 
Manufacturing. The CSO/Europe communicates with supporting sales offices and 
the customer services in the different European countries. Each of the organization 
units may consist of additional units. 

Distribution and Data View 

In the case of a single site business model, the data view will discern different data 
objects (types) that are used during business processes. For a multiple site business 
process model, we must allocate the data types in the data view to the different 
organizational units that were discerned in the organization view. One must 
determine which data should be managed at General Management, at 
Development, CSO, and Manufacturing. Within each of these units data may be 
allocated to sub-units. 

Given the data view and the organization view of a business model, the 
following indicators convey information about the degree of distribution: 

Data distribution: the number of unit/site-types where data-types have to be 
retrieved or to be updated by the processes in the business model; 

Local Types: for each unit/site-type, the (relative) number of data types required by 
the processes that are located on the site. 

Type distribution: for each data type, the number of site-types it has been allocated 
to. 

Distribution and Function View 

In the case of a single site model, the function view will discern the different 
activity types that make up the processes. For a multiple site business process, we 
must allocate the activities (types in the function view, executions in the control 
view) to the different organizational units that were discerned in the organization 
view. 

Given the function and organization view of a business model (set of 
processes), we propose the following indicators: 

Activity distribution: for each activity type, the number of unit/site types where the 
activity can be executed 

Activity density: for each site type, the relative number of activity types that are 
allocated to it. 
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In the EM case, for example, salesmen and supporting sales offices are two site 
types involved in order entry, order sending, order acceptance (activity distribution 
is 2), CSO is the only type performing an ATP-check (activity distribution: 1). In 
another allocation performing the ATP-check might be a task of the salesmen and 
supporting sales offices, resulting in an activity distribution of 2. 

Within the function view, activity- types can be linked to one- another by time- 
related demands such as synchronization or short response times. An example is 
the ATP-check and delivery date calculation for an order inquiry. 



high (highly . 

asynchronous) choices for a company 

as it becomes more 




centralized distribution in space ► distributed 

Figure 3 Simple heuristic guidelines for allocation. 

Dependencies between parameters can be identified. Reasoning within a 
primitive view is relatively simple. Alternate data and function allocations can be 
characterized within the three primitive views. At the level of primitive views of 
the business model simple heuristic rules, such as those represented in Figure 3, 
could guide allocations. Figure 3 indicates the choices a company has to make 
when it becomes more distributed in space (for example by opening new 
subsidiaries). For example, it may invest in technology to keep the same level of 
synchronicity (horizontal arrow), or not do anything special and put up with a 
higher distribution in time in the form of more communication delays(diagonal 
arrow). Figure 3 also suggests that, as new technology becomes available, the 
border between what is easy (cheap) to realize, and what is hard (expensive) will 
move in favor of allowing less distribution in time (more synchronous operation) 
or more distribution in space. In-depth calculation of performance indicators 
depends on the control view and the further derivation of models in design and 
implementation level. 
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5 PERFORMANCE OF AN ALLOCATION AND CONTROL VIEW 



In the control view, a reconstruction in space and time (following the 
decomposition of the process according to the three primitive views) of the 
business process takes place, in simulation (test) or in interflow (life/runtime) 
mode. Occurrences of sites and organization units are created, occurrences of data 
types (are stored in tables of databases and) participate in activity instances that 
make up the workflow of the business processes, either single site or multi-site. 

Activities follow the allocation of data to sites. Activities and information 
groups are allocated to the most suitable sites, with interface protocols and 
replication policies for other sites that need the data or activity. 

In the control view, detail and complexity is added, giving rise at the business 
level to indicators such as: 

• frequency of activities; 

• number of sites; 

• number of simultaneous users (average, peak, expectations); 

• response time: time required for activities and remote access; 

• currency of information: the interval within which information is refreshed. 

Alternate system designs can probably largely be characterized in the 
combination of the three primitive views. Allocating in the EM case the ATP- 
check to the sales offices, rather than to the CSO will result in a lower frequency of 
the activity per site. It will require on the other hand a larger effort to keep 
currency at an acceptable level: each office will have to propagate the sales it has 
closed to the others. How much exactly will depend on the choices made at the 
design and implementation levels. Ultimately, the performance of an allocation 
depends on implementation indicators, calculated from the available capacities for 
processing, storage, and communication. In the control view these choices are 
synthesized (in an upward fashion, integrating decisions made at implementation 
and design level, with the choices made higher up (in relation to the business 
process). For instance, the processing power needed for an ATP-check can be 
characterized in terms of the amount of CPU time it costs to extract the 
information from a local database and transform it into the number of items 
available at a certain date. 

At the requirements level other aggregate indicators also play a role such as: 

• cost of operation and of ownership; 

• resource requirements; 

• availability: the percentage of time activities can be performed; 

since decisions are usually based on an optimum involving multiple criteria. 

Indicators can be used in two ways. They can be used to reflect an actual 
situation, or they can be used to formulate a requirement for which an acceptable 
(in the multi-criteria sense) allocation has to be found. 

Analysts or consultants who model or redesign a business process in a 
distributed environment in preparation of the implementation of an ERP system 
often will use modeling tools to support them. Especially in the case of complex 
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software systems such as ERP software, good tools support is essential in gaining 
insight into the advantages and disadvantages of the different alternatives. This 
applies at all three layers (see Figure 1) and requires the collaboration of specialists 
for each layer. A business process designer will need to know if a certain set-up of 
a business process can be supported by the application and infrastructure, and must 
be able to verify this on the basis of a set of relevant indicators. Vice versa, an IT 
specialist will need to know the constraints arising from the business process and 
ERP software to tune the infrastructure. They will need to work together to 
construct a good compromise. An integrated tool supporting these activities will 
need to bring together the various aspects and thus must be founded on a sound, 
sufficiently expressive formalism. 



6 TOOLS 

In the previous section we discussed the impact of distribution on the four views 
and the three layers in the ARIS framework. One conclusion that can be drawn at 
this point is that distribution is a dimension of the model that is orthogonal to the 
four views already included. It should be made explicit at all three layers. 

To support a methodology for the development of distributed information 
systems, such as ERP systems, a set of integrated tools is required that allows the 
construction of the various ARIS views at all three levels. It should also support 
the expression of a mapping between related concepts in the views at each level 
and between the models at successive levels. Additionally, the tool set should 
enable the systems architect to express the distribution aspects of the system at the 
three modeling levels and then use the distribution models as a starting point to 
calculate the various performance indicators at each level. 

In this project we analyzed three formalisms for specifying information 
systems: ExSpect, LOTOS and SDL, and compared them with respect to their 
ability to express distribution aspects. ExSpect is based on hierarchical, colored 
Petri Nets (Hee, 1994), LOTOS on process algebra, and SDL is based on state 
transition diagrams (Turner, 1993). All three formalisms are designed to model 
dynamic, distributed information systems, and form the basis of a tools set to 
support the modeler, but none of them allows for the explicit expression of such 
entities as the physical location of a site, or the distance between sites. We 
therefore examined how these formalisms could be extended to incorporate such 
entities. 

Various approaches to extending formalisms can be taken. One can extend 
formalisms by adding new syntactic constructs to them, thereby enhancing their 
expressive power to the required level. This approach implies that a new version of 
the existing tool set has to be produced which can handle the new extensions. 
Although this approach is a fundamental one, and allows for a rigorous design and 
validation of the required constructs, it requires a major effort, both in terms of 
research and development, and we did not take it within the scope of this project. 
Instead we studied how the existing formalisms can be used to suit our purpose. 
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Another approach is to annotate the existing formalism, such as was done 
recently in (Faltin, 1997). When the annotations are embedded in the standard 
formalism, for example in the form of comments, a co-specification of regular 
(functional, data) aspects and distribution aspects is obtained. The existing tools 
can still be used for the regular part of the specification. A separate tool has to be 
constructed that extracts the annotations and constructs a distribution view on the 
model from them. The advantage of this approach is that all specifications can be 
kept in one place, which makes maintenance easier. Another advantage of the 
annotation mechanism is that it can be used to include a specification of the 
performance characteristics such as capacities. These annotations then could be 
extracted and fed into a simulation tool or an analytical model to calculate 
performance indicators. 

Since one of our goals is to be able to allocate activities to sites and then 
evaluate allocation alternatives with respect to some performance indicators, 
formalism extension through annotation appears to be an attractive option. 
Preliminary results from our analysis of ExSpect, LOTOS and SDL indicate that 
these formalisms, in principle, can handle annotations. The tools for these 
formalisms, however, also support a simulation mode. Instead of building a tool to 
feed the annotations into a separate simulation tool, a preprocessor approach could 
be taken. The preprocessor would take the annotated specification, express 
annotations in terms of the construction primitives for the simulation and this way 
generate an extended simulation model. The question here is to provide a suitable 
mapping from the annotations to the construction primitives. Such a mapping can 
be based on a number of standard constructions that can be instantiated for the 
purpose of simulation by setting parameters. Both ExSpect and SDL provide 
mechanisms to pass both data and function types as parameter. It therefore turned 
out that only a small number of construction primitives were needed to support the 
specification of the distribution and performance aspects we are interested in. We 
choose to pursue this alternative and are looking at a number of standard 
constructions. These constructions are used to model a number of cases, such as 
the EM case, to test their usefulness. 

Using the standard constructions directly, one can run simulations to evaluate 
performance of alternatives for distributed ERP system (for example for the two 
business cases cited above). Simulation is a useful approach for evaluating such 
alternatives in considerable detail, but it requires both time (runs have to made for 
each setting of the parameters) and skill to set up the simulation and evaluate its 
results (requiring a sound insight into statistics). Therefore we also considered the 
mathematical modeling approach for evaluating distribution alternatives. 
Preliminary results indicate that, although analytical models are less flexible and 
usually are less detailed, these models can be used, e.g., at the requirements level 
to get a quick, order of magnitude impression of the relative merits of various 
alternatives. This would provide support for a quick reduction of the number of 
alternatives to a short list of candidates that have to be looked at in detail. Also in 
this case, the annotations have to be extracted from the specification and mapped 
to a number of standard constructions. 
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7 CONCLUSION AND FURTHER WORK 



In this paper we looked at a number of questions related to the modeling of 
distributed enterprises to gain insight in the performance aspects of a multi-site 
ERP system and the way these are influenced by the allocation of resources. It 
appears that distribution has an impact on all levels of the ARIS framework and 
should be considered as an independent view on these levels. Just as the 
specifications at successive levels are related to each other (a specification at one 
level is derived from the one directly above it) as are also the distribution aspects. 
The relevant entities in a distributed system therefore are specializations of those in 
a centralized system, with added attributes such as location. 

Performance aspects of allocations have been analyzed in line with the ENV 40 
003 and ARIS architectures. This has resulted in an early taxonomy of indicators 
and a coarse view of the performance critical aspects of allocations, and their 
computational relations with performance. 

We also looked at the properties a syntax for modeling distribution needs to 
have, and we have proposed two viable alternative approaches . 

At present we are looking in more detail at the relations between the various 
levels and the way various choices influence each other. We are still experimenting 
with various choices for performance indicators using our standard constructions to 
gain some insight into their effectiveness for signaling potential performance 
bottlenecks. This should provide a sound basis for the next step: the incorporation 
of distribution aspects in a business modeling tool. 
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Abstract 

A critical component of any information infrastructure is a common understanding 
of the enterprise. Enterprise models enable this common understanding. The 
enterprise model can provide a comprehensive understanding of the environment 
the information infrastructure is designed to support. Models are typically 
developed from one of five perspectives or views. The different model views are 
presented and a comparison of these views is discussed. These five views are: 
business rule, activity, business process, resource, and organization views. The 
primary concern in this research is the identification of the issues of multiple views 
of an enterprise or system. Most project managers do not consider the issues 
pertaining to a multiple view model of a system. These managers develop and even 




maintain multiple types of models for different purposes. These multiple types of 
models are generally developed on an ad hoc basis. By understanding the issues 
relating to maintaining multiple views of an enterprise, the benefits of multiple 
views can be realized while minimizing its difficulties. Three approaches to 
integrating multiple views are explained and their relative shortcomings are 
discussed. 



Keywords 

Enterprise models, model views, extended enterprise, virtual enterprise 

1 INTRODUCTION 

A model is a representation of reality used for analysis, design, and decision 
making. Models contain information necessary for the task at hand while omitting 
unnecessary details The typical uses of modeling are (Marca and McGowan 1988; 
Nathan and Wood 1991; Snodgrass 1993; Reimann and Sarkis 1996): 

• To analyze and design the enterprise and its processes prior to implementation 

• To help reduce complexity 

• To communicate a common understanding of the system 

• To gain stakeholder buy-in 

• To act as a documentation tool for ISO 9000, TQM, Concurrent Engineering, 
and other efforts. 

An enterprise may be represented in many different forms. Each of these 
representations provides a different view or perspective of the enterprise. These 
different views are required to support the design, analysis, and implementation of 
the enterprise. A primary thrust of this research is to understand the relationship 
between the various enterprise views. This paper discusses the needs and issues 
with representing and integrating multiple views of the enterprise. 

1. VIEWS 

Multiple perspectives of an enterprise are required due to the various questions and 
viewpoints of the end customers of an improvement effort. Previous research 
defines a number of different views. Computer Integrated Manufacturing Open 
Systems Architecture (CIMOSA) promotes four views: Function, Information, 
Resource, and Organization (Vernadat 1992). The Zachman Framework of 1987 
(Zachman 1987) was extended by Sowa in 1992 (Sowa and Zachman 1992) and 
describes several different perspectives. Curtis (Curtis, Kellner et al. 1992), defines 
his four views as functional (what process elements are being performed, and what 
flows of information entities are relevant to these process elements), behavior 
(when process elements are performed (sequencing)), organizational or resource 
(where and by whom processes are performed, physical communications 
mechanisms, storage media and locations), and informational (what information 
entities are produced or manipulated by the process). The information entities 
include data, artifacts, products, and objects. ARIS (Architecture of Integrated 
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Information Systems) also has four views. The three main views used are data, 
function, and organization. Depending on context (information or business system) 
the fourth view is either called the resource or control view (Scheer 1994). 
Previous work in the development of architectures by the Automation & Robotics 
Research Institute (Presley, Huff et al. 1993) describes a five-view approach: 

• Business Rule (or Information) View defines the entities managed by the 
enterprise and the rules governing their relationships and interactions, 

• Activity View defines the functions performed by the enterprise (what is 
done), 

• Business Process View defines a time-sequenced set of processes (how it is 
done), 

• Resource View defines the resources and capabilities managed by the 
enterprise, 

• Organization View describes how the enterprise is organized which includes 
the set of constraints and rules governing how it manages itself and its 
processes. 

However, this does not mean that all these views must be present in all models. A 
model is an abstract representation of reality which should exclude details of the 
world which are not of interest to the modeler or the ultimate users of the model. 
Models are developed to answer specific questions about the enterprise. If the 
information modeled in a particular view is unnecessary to answer these questions, 
it may not be necessary to create the view. This research focuses specifically on the 
need for analysis of resource constraints and process flows. Most of the authors 
cited in the previous paragraphs, along with others have commented on the 
difficulty in relating the views to each other and maintaining consistency. This 
paper attempts to identify some issues of maintaining multiple views and provides 
some examples. 

THE NEEDS OF MULTIPLE VIEWS 

This section begins by describing a unique categorization of process types. This 
categorization is then used to describe the concepts underlying an extended 
enterprise. An additional concern regarding the use of models in general is then 
addressed as the concept of a living model of the enterprise is described. 



Categories of Processes 

Presley, et al., (Presley, Huff et al. 1993) propose that business processes may be 
placed into three categories: (1) those processes which transform external 
constraints into internal constraints (set direction), (2) those processes which 
acquire and make ready required resources, and (3) those processes which use 
resources to produce enterprise results. By providing categories to organize 
processes, more holistic enterprise designs may be achieved. Figure 1 shows 
activities (boxes) arranged into business processes (ellipses). The business 
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processes are organized into an enterprise represented by the larger box. At this 
high level of abstraction, the enterprise itself is represented as an activity that takes 
inputs and transforms them into outputs using available resources under the bounds 
of a set of constraints. 

Frequently the only activities or processes considered in modeling and 
improvement activities are those listed as category 3 which transform inputs into 
products and services. However, it is as important to consider the strategic and 
acquisition activities in an enterprise. Understanding the different process 
categories is vital to develop useful representations. Categorizing the different 
processes helps to ensure that the frequently overlooked categories of setting 
enterprise direction and acquiring and preparing resources are considered. 

Enterprise 




Set direction 



Transform 



Acquire Resources 



Figure 1 ; Process Categories 



Extended Enterprises 

The concept of a virtual or extended enterprise introduces several issues in the 
representation of an enterprise. An extended enterprise expands the scope of a 
model from bounding a single enterprise to include additional processes performed 
by other enterprises. Defining and coordinating all of the business processes 
comprising an extended enterprise is significantly more difficult than coordinating 
the actions of a single business entity. The increased interaction between the 
various enterprise processes adds to model complexity. The operation of a process 
oriented and highly flexible extended enterprise mandates that all activities, 
information, resources, and organizational issues be carefully integrated. 
Traditional process modeling and planning methods do not address the unique 
needs of inter-enterprise activities. This lack of support for the unique needs of the 
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extended enterprise is in addition to the shortcomings discussed earlier. Figure 2 
shows that the enterprise consists of a set of business processes from category (1) 
which are owned by each individual enterprise. The other enterprise models need 
not contain the details of category one processes. Category 2 and 3 processes 
relevant to the extended enterprise are included in all models. The formation of 
each extended enterprise should be viewed as a temporary or transient state. These 
enterprise structures should have the ability to form and dissolve based on dynamic 
market opportunities. This dynamic nature of the extended enterprise presents 
significant challenges to the modeling methods and tools designed to represent 
them. These extended enterprise modeling approaches must represent the core 
business processes of each business entity participating in the virtual organization. 
The model must also support the frequent addition, subtraction, and 
reconfiguration of models that represent the transient processes performed by the 
extended enterprise. The ability to support the frequent reconfiguration of the 
enterprise model to reflect the nature of an evolving enterprise requires the creation 
of a living model of the enterprise. 

Extended Enterprise 



Category 1 business processes 
owned by individual enterprises 
to Develop Enterprise Objectives, 
Strategies, Tactics & Plans 



Category 2 & 3 
business processes 
individuaily owned 
and managed to 
market, design. 






Enterprise A 




t 



Enterprise B 




I 




Enterprise C 




I 



Figure 2: Extended Enterprise 
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A Living Model of the Enterprise 



An additional consideration to that of views or perspectives relates to the actual use 
of the model. The authors propose that the use, both future and present, of the 
model is vital to ensuring that the model serves the enterprise in the most effective 
manner. To this end, a living model of the enterprise is proposed. A living model 
of the enterprise is defined as a model that drives, and is driven by, the daily 
operations of the enterprise (Whitman and Huff 1997). These living models of the 
enterprise can be classified along three dimensions. Figure 3 shows these 
dimensions to be scope, enactment, and the dynamicness of the model. A 
description of each of these characteristics follows. 




Figure 3: Living Model Dimensions 



Scope is the pervasiveness of the model throughout the enterprise. Enterprise 
modeling by its very nature is intended to provide a holistic representation of the 
entire enterprise. It is sometimes necessary to bound the model to a subset of the 
enterprise. The bounds describe the scope of the model. Enactment is the level in 
which the model drives and is driven by the system. There is a wide variation in 
the enactment capabilities of a living model. A model can range from no enactment 
at all to driving the entire enterprise and providing all inputs and reporting the 
status of the enterprise when requested. Some more likely phases of enactment 
might be to use a work flow arrangement which can provide either direction to 
enterprise personnel allowing them to deviate slightly from the process or require 
strict adherence to the process. Dynamic is the ability to respond to both permanent 
and temporary process changes to the system. As has been previously discussed, an 
important living characteristic of an enterprise model is its ability to change. This 
dimension denotes this ability. Most models today do not facilitate the ease of 
change for the model. The phases of dynamic range from no capability to the 
model itself being capable of learning from its environment and then modifying 
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itself to reflect and implement the new process. This dynamic dimension is not to 
be confused with simulation models, which are often called dynamic 
representations. 



ISSUES BETWEEN VIEWS 

In this section we discuss four key issues in the synthesis between views. These 
issues are: 1) gaps in the view, 2) differences in methodology structure, 3) artificial 
wrappers (decomposition versus aggregation), and 4) model ambiguities. 

Gaps in the view 

The primary reason for modeling is to answer a question. Details that are important 
to the question answered by the model are included. Therefore, some information 
that is pertinent in one view may not be relevant in another view. This is the 
advantage of modeling multiple views of an enterprise. While there is significant 
overlap between the activity, process, and organization views, there are also 
significant portions of each view that are not described in the other views. All 
information about a given system or enterprise can not be represented in a single 
view. Complex questions regarding the enterprise often require analysis across 
multiple views of that system. While the various modeling methods are capable of 
representing each of these enterprise views independently, they do not directly 
support the integration of their view with the other modeled enterprise views. This 
lack of view integration inhibits the development of a holistic understanding of all 
the diverse, yet interrelated, concepts and issues which can impact the performance 
and behavior of the modeled system. 

Artificial Wrappers 

Models are frequently created with a hierarchical structure that provides a useful 
tool for understanding an enterprise or system. Hierarchical modeling utilizes a 
subordinate principle of abstraction called decomposition (Rumbaugh, Blaha et al. 
1991), which is the breaking down of each activity into more detail in a continuous 
manner until the greatest level of detail is achieved (Marca and McGowan 1988). 
An example of this top down modeling strategy, as used in the IDEFO method, is 
shown in figure 4. 
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Figure 4: Functional Decomposition 



While the use of hierarchical modeling strategies are beneficial due to their ability 
to hide system complexity, the modeling procedures dictated by the methods often 
force the definition of abstracted entities which are not readily recognized by 
individuals familiar with the system. Most of the reviewers of models are familiar 
with either the top levels of the system or with the bottom levels of the system. 
Generally familiar “labels” for these levels are used that provide a frame of 
reference for these reviewers. In the previous figure, the A-0 and AO level would 
likely use similar terms for the activities identified at these levels. Also, the A23 
level would also use familiar terms for the activities at lower levels. However, the 
middle level activities, such as those in A2, might not be recognized by anyone 
familiar with the system. Therefore, to properly decompose these activities, an 
“artificial wrapper” is placed on groupings to aggregate the lower level activities to 
match these with the higher level activities. Most systems are well defined at the 
high levels and at the low levels, but are not explicitly defined at the middle levels. 
In the author’s experience, this has confused many model reviewers. 

Differences in Structure 

The structures of the various views are not necessarily conducive to mapping 
between views. Activity and process views facilitate a hierarchical representation, 
whereas, the data view does not. A high level activity view may contain 
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“documents” as a data element, and a lower level activity view contains “work 
authorization.” The data view would contain only the element “work 
authorization” with the data required on the fields of the form. A mapping 
technique might be to only map the lowest level of the hierarchical method, but 
this approach loses the advantages of a hierarchical model in reducing the 
complexity of the system and increasing the understanding of the system. 



Model Ambiguities 

Information that is pertinent in one view is frequently not included in another view. 
This reduction of information is useful for a clearer understanding of the system. 
However, this also leads to ambiguities in the model. Some concepts are easy to 
represent in one view of the model, but in the complementary view, additional 
information is required to remove ambiguities. Additionally, an alternate 
representation of the same concept in different views often leads to ambiguity. Part 
of the ambiguity arises from the very nature of the views and their focus. For 
example, the process view by necessity focuses on the transformations that objects 
and information in the enterprise go through. While the objects and information 
transformed are usually shown in the view (although some modeling methods may 
not explicitly identify them), the focus is still on the transformation. On the other 
hand, these same objects and information would be the primary focus of the 
business rule or information view. The transformations that might have bound the 
objects together in the activity view may be hidden or not shown at all in the 
information view. Also, some views enforce artificial decompositions on objects. 
This is the case in some information view methods, which break apart real world 
objects into abstract concepts to support the needs of the view. They may also 
create new concepts, which do not actually exist in the real world, again to 
facilitate the representation of the view. So a user wanting to analyze a concept in 
one view might have difficulty identifying the concept in another view or may find 
that the concept has been divided into several other concepts in the other view. 
While object oriented approaches help mitigate some of these ambiguities, these 
inter- view ambiguities still exist. 

In addition to inter-view ambiguities, reduction of information may lead to intra- 
view ambiguities. We clarify this point with the following example. In figure 5, an 
activity is shown with two inputs. This is a correct representation of the process, 
but it is ambiguous. The two inputs represent one of three conditions. An assemble, 
a match, or a selection. An assemble means the two inputs could represent two 
items needed for the activity together. An example could be a motherboard and a 
cpu. Any one motherboard may be assembled with any cpu (assuming this is a line 
with only one cpu and one type of motherboard). A match means that a specific 
instance of Input 1 must be matched with Input2 for the activity to occur. An 
example could be a part to be machined and its part program. A selection means 
that only one of the two inputs are needed for the activity to occur. An example of 
this can be seen in figure 6. This example shows where the part is being 
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manufactured and if not correct cycles back to the manufacturing process. 
Therefore, either type of input is required for the activity to occur. 



Control 
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something 


inputs: 
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Figure 5: Example of ambiguity 
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CONCLUSION/FUTURE RESEARCH 

A comprehensive understanding of the need and issues related to multiple views of 
an enterprise can aid in the implementation of intelligent manufacturing systems. 
This paper discussed the five perspectives typically used in most modeling efforts. 
Most analysis efforts develop and maintain multiple types of models for different 
purposes. Resolution to the issues identified in this research related to the 
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inconsistencies encountered in modeling are critical to improving the design and 
analysis of any system. By understanding the issues relating to maintaining 
multiple views of an enterprise, the benefits of multiple views can be realized 
while minimizing the resultant difficulties with the consistency of multiple views. 
Some methods reduce complexity to aid in achieving understanding. However, this 
is not without cost. The reduction of complexity is achieved by the reduction of 
details. These details are critical for certain purposes such as temporality. Multiple 
views enable the reduction of complexity in one view and allow the vital details to 
be described in another view. 

Presley (1997), provides an IDEFO model describing his methodology. He 
integrates the views through the IDEF5 Ontology Capture Method. An IDEFO 
model describing the methodology is shown in figure 7. The IDEF5 model serves 
as the business rule view. The necessary relationships are extracted from the 
IDEF5 model and are used to specify the organization and resource views. Activity 
information from the IDEF5 model is used to generate an IDEFO activity view and 
IDEF3 business process view models. 
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Modeling Needs C2 Note: Heavy arrows indicates main path of model as more of the 

Environment Cl I Model Feedback process tempiate is instantiated. 
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Figure 7: View Synthesization Methodology (taken from Presley, 1997) 








The resolution of these model view integration issues is becoming increasingly 
more important as the complexity of our manufacturing enterprises continue to 
increase. The lack of simple model integration strategies will hinder the 
development of living models of the enterprise. Our research will continue to 
explore the courses of poor model view integration as we undertake the next 
generation of enterprise model strategies. 
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Abstract 

Industrial enterprises are increasingly forced to design their products for the 
environment. As environmental effects result from processes throughout the 
product life cycle, product and process information must be integrated in a 
conceptual model to realise systems of information technology that support 
product design and manufacturing. This paper presents a new method to derive an 
object-oriented information model from a life cycle oriented modelling approach. 
The information model consisting of a product data model and several partial 
models representing life cycle phases can be implemented easily, e.g. as an object- 
oriented database, which is a basis for life cycle impact assessment and its 
integration with a design system environment. 
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1 INTRODUCTION 



Industrial enterprises are increasingly forced to develop and manufacture 
environmentally sound products. To meet this requirement it is necessary to 
analyse processes in all life cycle phases regarding environmental impacts. 
Important is the relationship of these process effects to product properties in order 
to optimize products and production during development. A powerful software 
support for this optimization can be developed if a formal information model is 
created that represents the process information and its relationship to a product 
data model as developed in ISO 10303 (STEP). 

On the one hand, for an efficient implementation of IT Systems an object- 
oriented information model is required. On the other hand, the knowledge 
resulting from analysis of production processes can be represented more easily in a 
process oriented manner. As behaviour description in object-oriented modelling 
languages is complex, simple process modelling languages would be preferred, 
arising the need for supporting a transformation to a modelling language that is 
computer accessible. 

As production processes within a particular enterprise are supplied with raw 
materials and semi-products and followed by product use, recycling and disposal, 
the analysis must be extended over all participating enterprise departments and 
their suppliers. Therefore a support for co-operation during information model 
development is necessary. 

Contemporary methods of information modelling do not offer a special support 
for transforming process models into object-oriented models as a basis for IT 
systems. A new information modelling technique that includes such a 
transformation has been developed within the research project "SFB 392: 
Development of Environmentally Sound Products”^ at Darmstadt University of 
Technology. This approach of an interdisciplinary group of scientists develops a 
design system environment that includes an holistic assessment of product and 
process alternatives depending on environmental but also technical and 
economical properties. An important task within the research project is the analysis 
of processes in product life cycle and the representation of this knowledge in a 
formal information model. Core of this model is a product data model based on 
ISO 10303. Several partial models represent views of particular product life cycle 
phases. 

The following chapter will discuss the need for process oriented modelling 
techniques despite an object-oriented implementation. Known approaches to 
transform process models towards implementation will be analysed. The 



^granted by the German research association (DEG) 
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developed modelling technique and its tool support will be described with focus on 
the transformation process. 



2 COMPARISON TO OTHER APPROACHES 

For the development of IT systems supporting design for environment, process 
modelling can be used in two ways: For analysis of the product development 
process in order to define the tools supporting the development of environmentally 
sound products, or for identification of processes from life cycle phases with 
relevant impact on environment. Especially the first case is comparable to ISO 
10303 Application Protocol Development: First of all, application and modelling 
experts describe the application in terms of processes to define the scope and to 
identify the information flows that must be supported by data exchange, in an 
activity model using the process modelling language IDEFO. 

The information flows are detailed in the reference model using the more object- 
oriented description language EXPRESS-G. A transition of activity model to 
reference model is based on a clustering of information flows in the activity 
model. The reference model is structured in Units of Functionality each describing 
the information requirements of a restricted group of application functions or 
processes in the activity model (Mohrmann, Katzenmaier, 1997). 

As a basis for the implementation of data exchange processors, the information 
requirements specified in the reference model are mapped to suitable constructs of 
the application independent integrated resources of ISO 10303 to ensure 
consistency between multiple application protocols (Anderl, Wasmer, 1996). This 
task is not comparable to the integration of partial models with a core model in the 
research project described - whereas an application protocol uses constructs of the 
integrated resources of ISO 10303 in a special application context, the partial 
models detail and reference core model constructs to specify environmental 
impacts in all life cycle phases. 

In the area of business process reengineering an integration of process and 
product models is performed by various methods, but without any transformation 
of the process model (Kosanke, 1996). 

A quite different approach transforming process models directly to object- 
oriented structures has been implemented for IDEFO to EXPRESS in the software 
tool XP-IDEF by CSTB. It is based on a reference schema for the process 
modelling language and can be used to produce a neutral STEP version of IDEFO 
models or to transform them into different reasoning frameworks (CSTB, 1998). 

Of course, process models themselves can be specified formally without any 
transformation, e.g. using a description language with dynamic constructs as UML 
(Booch, Rumbaugh, 1997) or EXPRESS-C (Staub et al., 1994). But this object 
oriented information modelling not only requires understanding of its philosophy, 
but also programming experience. 
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To support an analytic approach and active participation of non-modelling 
experts in an information modelling project, the use of an informal modelling 
language is advantageous. In later phases, the information model must be 
formalised in order to become unambiguous and computer accessible supporting 
its fast implementation. As a result, an information model - in particular for 
product and environmental information - should be formalised step by step. 



3 METHOD FOR TRANSFORMATION OF PROCESS MODELS 

As an example for the transformation of process models in order to create an 
information model for environmentally sound products, the IDEFO language is 
chosen as a process modelling language. The object-oriented language to be 
transformed to has been developed based on EXPRESS-G in order to achieve a 
fully graphical representation, easier to use as UML but with more capabilities 
than EXPRESS (Anderl et al, 1997). This approach facilitates reuse of ISO 10303 
models, but also considers the requirement to represent all environmental product 
information, e.g. ecological assessment data based on functional and rule-based 
dependencies. 

Concerning the process modelling language, IDEFO has some advantages 
against others such as an easy structure and a support for analysis of processes by 
detailing them. The transition concept of Petri nets as another kind of process 
modelling rather aims at simulation of processes, not analysis and identification of 
process properties. In the area of life cycle assessment, a framework based on 
IDEFO has already been defined (Tipnis, 1995). The usage of IDEFO within the 
research project SFB 392 for the identification of environmental impacts and 
parameters with significant influence on environmental product and process 
properties is shown in figure 1 . 
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Figure 1: Usage of IDEFO for environmental process analysis 
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As the main difference between mechanism and input, it has been defined that 
mechanisms are nearly independent from processing a particular product. Both 
inputs and mechanisms can result from other process chains not included in the 
process model - the distinction between various levels of process chains is 
important for defining the scope of life cycle inventory calculation. 

The transformation of such IDEFO process models into object-oriented models 
needs to be realized by an incremental transformation technique. The steps of this 
technique are shown in figure 2. 



Activity 

A-0 



ui 





1 . creation of entire 
process presentation 




(generated) 



entire process presentation 




structured formal model 



A1 




A3 


attributes 




attributes 




*C| CCN9TRAH 


IS 


C1 


I J 


A22 


attributes 


M 


attributes 






C2 


■-o 


attributes 



3. definition of types 
and model structure 




(supported / manual) 



2. identification of 
relevant processes 



t (supported / 
manual) 



initial formal model 



A1 




A22 




A3 


ICOMs 




ICOMs 




ICOMs 













Figure 2: 



Transformation of life cycle models into product data models 



The main aspect is, that activities are grouped to classes and their ICOMs (input, 
output, control and mechanism) become static or dynamic attributes of these 
classes. A reverse approach to create classes from the ICOMs and to represent the 
activities by dynamic constructs did not prove useful in the given context. 

The technique is based on the assumption that the lowest level activities of an 
IDEFO model contain all aspects of the process. These activities are used for a 
coherent representation of the real world process. From this representation, an 
initial class diagram is developed which contains classes representing activities 
relevant for the given context. ICOMs from the process model start as attributes 
without types. In the following step, the initial class diagram is transformed into a 
structured model. All classes have to be checked for aggregation or inheritance 
relationships between them, and correct types of class attributes must be identified 
distinguishing the following: 
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1. The class attribute represents a single atomic value or a set of atomic values. 
In this case, the attribute has to be defined as a Simple Type (e.g. REAL, 
FUZZY_SET etc.). 

2. The class attribute has a structure important for the given context. Then the 
attribute is deleted and a new class has to be created containing the relevant 
properties. 

3. The attribute belongs to a different class. It is deleted from this class and 
defined in another one. 

4. The value of the attribute can be calculated by a function or a rule. The 
attribute is deleted, and it must be determined which dynamic construct is 
used to represent it. 

5. The attribute is unimportant and can be deleted without any other actions. 

To support processing of case 4, the modelling language developed on the basis 
of EXPRESS-G includes dynamic constructs. These extensions to EXPRESS-G 
can be divided into constructs for representing functions, rules, constraints and 
informal dependencies, but use a common logical structure for modelling and 
follow object-oriented principles. 

Mathematical functions are represented either as a function or a table construct. 
A function consists of an arithmetical combination of numerical or string 
attributes. In the context of environmental information, there are a lot of 
relationships between product and process parameters, which cannot be expressed 
by a simple formula. To represent such relationships (i.e. measuring data), the 
table construct is used. A Table maps multiple columns - probably containing 
numerical attribute values as well as alphanumerical - to a result in the last column. 

For representing rules, constructs for condition and implication are defined and 
can be combined by Boolean operators. The implication contains a list of 
statements which change the attribute values of a class. 

Constraints can also be represented graphically to specify - for example - 
restrictions of attribute values for instantiation or modification of objects in a 
database. Objects of a class are valid, if all constraints are satisfied. 

To represent information hard or senseless to formalise, the element document is 
defined. A document references class attributes where external (possibly 
multimedia) documents e.g. describing guidelines for product design are assigned 
to. 

The resulting model can be further processed by representing additional static 
and dynamic aspects. Then an integration with an existing product data model can 
be performed by links between the partial and core models. These links are defined 
as supertype or attribute relations or as references for use of class attributes in 
dynamic constructs. 
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4 IMPLEMENTATION OF MODEL TRANSFORMATION 



The method to transform process models into object-oriented models and its 
implementation in software systems is realised with a suitable modelling tool 
developed within the research project. It supports the entire model development as 
a basis for providing transitions between the modelling steps (figure 3). 

To support a co-operation between partial model developers, all modelling steps 
can be automatically documented as HTML including image maps of the graphical 
model representations. 

Special functions have been implemented for deriving a consistent process chain 
out of an IDEFO process model. To solve the hierarchy of IDEFO, any process is 
decomposed into its sub- activities until an elementary activity is found. Then a 
class is generated for that activity and all ICOMs of this process are added as 
attributes automatically. By browsing through all levels, the order and the flows 
between elementary activities are determined, so an entire representation of the 
process model without redundancies can be created. 




Figure 3: Tool support for modelling process 



Another tool feature important for modifying the initial class diagram is a fast 
redefinition of element types to replace simple class attributes efficiently by more 
sophisticated constructs such as functions, rules, constraints or classes as 
described. 



159 





Validation of developed partial models is performed using a graphical 
instantiation language. This language provides constructs to instantiate classes, 
their attributes and relations. 

Then dynamic elements derived from attributes within the object-oriented model 
must be calculated and visualised by functions of the modelling tool. 

Any partial model can be integrated with a product data model by importing it 
into the partial model as a read only component. Finally, all partial models 
developed to represent product life cycle phases are combined on the basis of the 
product data model. A check for redundancy between the partial models in the 
entire information model can be performed with some tool support. Concerning 
the model contents, an analysis by a modelling expert in co-operation with the 
partial model developers is required to ensure a consistent information model. 

The modelling tool also includes a compiler to create a database schema directly 
from the information model. The schema clearly corresponds to the information 
model which simplifies initial database instantiation as well as keeping the 
information up-to-date. Another important aspect is the derivation of Interface 
Definition Language {IDL) from the information model to specify the interfaces 
between database and application system. 



5 IMPLEMENTATION OF INFORMATION MODEL 

The object-oriented approach for the information model including dynamic 
properties of a product and its processes enables a fast implementation in an 
object-oriented database system. The database is the main component for the 
design system environment currently being developed in the research project. Its 
system architecture is based on the Common Object Request Broker Architecture 
CORE A (OMG, 1996). Additional systems required for the development of 
environmentally sound products are integrated or implemented respectively using 
the interface description specified in IDL\ 

A parametric 3D-CAD system is used to instantiate the core model part of the 
information model with product data. A so-called life cycle modeller is used to 
select processes represented by partial models, if the process chain cannot be 
derived directly from product properties (Schott et al., 1997). This life cycle 
modeller includes components for each life cycle phase that are used to add 
product specific process information during product development, as well as 
enterprise specific information during system configuration. Direct interfaces to 
the database are used to instantiate all data which are independent from a specific 
product or enterprise. Based on this information provided by CAD and the life 
cycle modeller or instantiated initially, an assessment system for environmental 
and also technical and economical properties of products accesses the assessment 
data calculated in the partial models and performs a life cycle inventory and 
impact assessment that is presented to product developers in a suitable manner for 
optimising the product’s environmental properties. 
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6 CONCLUSIONS AND FUTURE WORK 



The presented modelling transformation simplifies the modelling process in the 
research project SFB 392 and facilitates a rapid prototyping of a design system. 
The methodology seems to be transferable to the design of other IT systems if they 
are based on process analysis. A transformation of knowledge represented in other 
forms than an IDEFO process model is also planned in order to create object- 
oriented models even from informal enterprise knowledge. 

To ensure completeness and correctness of the information model for 
environmentally sound product design, a sophisticated collaboration support 
during information modelling will be developed. For integrating external 
information sources with this information model it is planned to generate 
mappings automatically. 

An interface for enterprise configuration and instantiation of the information 
model will provide future application of the described design system basing upon 
information model in enterprises. The first prototype of the design system is 
currently being implemented. 
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Abstract 

Manufacturing systems are complex entities, comprised of people, processes, 
products, information systems and data, and material processing, handling, and 
storage systems. Because of this complexity, systems must be modeled using a 
variety of views and modeling formalisms. In order to design and properly 
integrate system functions, the multiple views and models must often be considered 
simultaneously. However, no single tool or computing environment currently 
exists that allows this to be done in an efficient and intelligible manner. Virtual 
Reality Modeling Language (VRML) provides a variety of features which make it 
attractive for use in developing such environments. This paper describes how a 
team at Virginia Polytechnic Institute and State University (VPI) and the National 




Institute of Standards and Technology (NIST) is using VRML as a hybrid 
manufacturing-modeling environment. Different manufacturing scenarios that are 
being investigated with the environment and future research directions are also 
discussed. 



Keywords 

Manufacturing Systems Modeling, VRML, Multi-dimensional Models, 
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1 INTRODUCTION 

Manufacturing systems are complex — they are comprised of people, processes, 
products, information systems and data, and material processing and handling 
systems. In order to design effective and efficient systems and integrate the various 
components, manufacturing systems modeling is required. Because of system 
complexity however, systems must be modeled using various views, e.g., 
functional, informational, physical, control, etc. Models in each view can be 
developed using one or more software applications employing various modeling 
formalisms. Some examples of modeling formalisms include IDEFO, EXPRESS, 
flowcharts, 2D and 3D simulations, system and data flow diagrams, plant layouts, 
part designs, virtual prototypes, program logic and code, organization charts, 
process plans, Gantt charts, and various text specifications. New representation 
schemes and formalisms are being developed all the time. In order to properly 
integrate system functions, these multiple views and models must be considered 
simultaneously. At present, no single tool or computing environment exists that 
allows an arbitrary set of views and models to co-exist and be used together in an 
efficient, intelligible way. Additionally, many applications are not intended to 
work together and hence file formats are often incompatible. As a result of these 
deficiencies, users are often forced to deal with multiple tools simultaneously, 
switching from one application to another as required. The use of modeling tools 
in this manner is both inefficient and detrimental to the decision-making process, 
and seriously impacts the time it takes to design manufacturing systems and 
products. A software environment is needed that allows different representations to 
be combined and shows the various relationships between different models, and 
which can deal with incompatible file formats. 

This paper describes the work underway by a joint team at Virginia Polytechnic 
Institute and State University (VPI) and the National Institute of Standards and 
Technology (NIST) to use Virtual Reality Modeling Language (VRML, 
pronounced "vermel") to tackle these problems. VRML is a scene description 
language, which can be used to describe 3D environments over the Internet 
(VRML, 1997). Because of its inherent flexibility, portability, and open structure, 
VRML may provide that common environment for integrating multiple views and 
models of manufacturing systems. 
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2 BACKGROUND 



A review of the literature shows that a wide range of modeling techniques have 
been developed and adopted over the years. Vernadat (1996) states that an 
important part of modeling manufacturing systems is to consider the various 
aspects: functional, informational, resource and organizational. Additionally, there 
should be a way to view the various data at different abstractions and in different 
modalities (Mize et al, 1992). The majority of work dealing with simultaneous 
consideration of multiple views and models in manufacturing has been performed 
through research on manufacturing (enterprise) architectures. Various 
architectures, such as CIM-OSA (AMICE Consortium, 1992), the Purdue 
Enterprise Reference Architecture (Williams, 1992), the GRAI model (Doumeingts 
et al, 1992), and the lEM approach (Mertins et al, 1991) propose different views 
and models for modeling manufacturing systems throughout their life-cycles. Very 
little work has been performed, however, directed specifically at the development 
of software environments for dealing with the multiple views and models which 
result simultaneously. 

Three-dimensional interfaces like VRML present a promising approach for 
tackling this problem. This approach is advocated by Yang (1996), who points out 
that the development of generalized models and an open-system architecture are 
essential efforts that should go into the future development work for virtual 
manufacturing. Despite its potential, however, the use of VRML in manufacturing 
to-date is limited. Most of the work done using VRML has covered applications in 
the sciences. The few reported engineering applications of VRML have been in 
such fields as civil engineering and architecture (Dodge et al, 1997; Smith et. al, 
1997). Some work has been performed to show how VRML can be used to access 
manufacturing data (Ressler et al, 1997) and illustrate pick-and-place capabilities 
of robots (VRML, 1997). 

Recently, researchers have started focusing on object-oriented technology to 
solve the issues facing manufacturing systems modeling. In addition to introducing 
modularity into the modeling environment, object-oriented technology might be a 
better way to solve the problem of configuration-on-demand (Mills et al, 1992). 
But again, the object-oriented languages, which exist in the market today, are 
usually restricted to the two-dimensional frame-of-reference. Though VRML itself 
is not object-oriented, it allows for the incorporation of other object-oriented or 
scripting languages, such as Java and JavaScript. 
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3 USE OF VRML FOR MANUFACTURING SYSTEMS MODELING 

3.1 What is VRML? 

Just as HTML (Hypertext Markup Language) is a file format that defines the layout 
and content of 2D pages with links to more information, VRML is a file format that 
defines the layout and content of 3D worlds with links to more information. The 
links can be either to HTML pages or to other VRML worlds. Unlike HTML, 
however, VRML worlds are spacious and inherently interactive - filled with objects 
that react to users and to each other. 

VRML is a platform-independent language, which makes it portable across 
platforms with no difficulty. Some of the other features of VRML include 
specification of camera positions (called "viewpoints"), turning visibility of objects 
in the VRML world on and off, the ability to employ animated objects, provisions 
for database connectivity, and the ability to incorporate multi-user options. 
Viewpoints are one of the more powerful features of VRML. They allow the user 
to be transported to specific camera positions within the virtual world. There are 
no restrictions on the number of viewpoints in a VRML world. VRML also 
provides the ability to attach animations to viewpoints. This feature is useful if one 
intends to view animation from a particular camera position. The user also has the 
ability to move around in the virtual world ("cruise") on his/her own. Finally, 
objects can be included as “billboards” into virtual worlds. These objects can be 
either two-dimensional or three-dimensional and have the ability to orient 
themselves to the user as the user moves through the virtual world. Caution should 
be exercised in using this feature, however, as seeing only the front face of the 
object might not be the intention of the user. 

3.2 Relevance of VRML Functionality to Manufacturing Systems 
Modeling 

As previously described, manufacturing systems are extremely complex entities, 
which must be studied using multiple views and models. The sheer amount of 
information and variety of information types and relationships which exist for such 
systems make it extremely difficult for any user to obtain an accurate, detailed 
understanding of the system via two-dimensional models developed using stand- 
alone applications. At the same time, the incompatibility of the various file formats 
used for different applications hinders the ability to develop integrated modeling 
environments. VRML is able to tackle both of these problems simultaneously. 

Through extensive use of three-dimensional modeling features, VRML is able to 
give users a much clearer picture of the manufacturing system via different views 
and models. Objects in different models can be linked with each other using "hot 
links,” in a similar manner to HTML web pages. The links can be used to connect 
to different types of modeling artifacts (e.g., physical object, function box. 
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information flow, etc.) via the use of different modeling formalisms (layout 
diagram, activity network, data flow graph, etc.). Multiple viewpoints allow the 
user to "move" to particular locations within a model, and to then view the various 
objects in the model from that position, using various orientations. Additionally, 
multiple viewpoints can be used to move the user between different models as 
desired. Animation can be employed to show system behavior over time, while 
turning visibility on and off can be used to effectively isolate select models and/or 
objects, bringing them to the foreground. 

The incompatibility problem is addressed via the platform-independent nature of 
VRML. Because of its neutral file format, most of the formats employed by 
different modeling packages can be translated to VRML. This allows for easy and 
efficient use of various modeling formalisms in the same VRML world. 

3.3 Application of VRML to Manufacturing Systems Modeling 

To integrate the various views of manufacturing systems, each view is represented 
as one or more levels in the environment. Since the quantity of views may vary 
according to the user’s perception of the system, the quantity of levels in the 
environment is variable: users can add/remove levels (views) as necessary. 
Features like changing the spacing between the levels, changing the orientation of 
the levels, and providing a fly-through of the environment can also be provided. 
These will allow the user to “customize” the presentation to suit his/her taste. 
Different types of manufacturing system objects, models, and data can be displayed 
on each level. The physical view for instance, could consist of a single level 
containing a three-dimensional model of the facility, with objects representing the 
various machines, conveyors, storage facilities, etc. The animation capability of 
VRML can be used to illustrate the machining operations being done at this level. 
Models at each level can be represented according to one or more modeling 
formalisms: the representation used depends on the application and requirements. 
IDEF and EXPRESS are commonly used for functional and information modeling. 
If more than one modeling formalism is to be used at a given level, the resulting 
models can be located adjacent to one another in different segments of the same 
level. A further enhancement might be to consider representing the various models 
via graphs, with each model as a separate node. To study the different views and 
models, the user can cruise to a particular level, viewing the level from any desired 
orientation and position. An improved approach is to provide viewpoints, allowing 
the user to move to a particular location to view the level. One of the advantages 
of providing viewpoints is that the user can always track the way back in case 
he/she loses place in the three-dimensional virtual world. In addition to moving at 
a particular level, the user can move between levels as well. 

An important problem in manufacturing system modeling is to show the mapping 
between various views and the activities. The ability to provide hot links in VRML 
worlds can be used to advantage for mapping functions between the various views. 
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Apart from the above features, the flexibility and ease of programming of VRML 
makes it ideal for building the hybrid-modeling environment. 



4 PROTOTYPE APPLICATION 

4.1 Application Description 

The prototype VRML environment for manufacturing systems modeling is being 
developed for the domain of fabrication facilities, with the focus on machining 
processes. The environment consists of three levels: physical processing systems 
(physical view), information systems (physical view), and systems architecture 
(functional view), as shown in Figure 1. A brief description of the various levels is 
given below. For additional details, readers are referred to Krishnamurthy et al. 
(1997). This work is on-going, hence some of the features mentioned are still 




Figure 1 Levels in the Virtual Manufacturing System. 

4.1.1 Physical Processing Systems Level 

The physical processing systems level is used to model the items and facilities used 
for executing physical processing (manufacturing) activities. A single model is 
currently employed, the physical processing systems model. This model contains 
three-dimensional models of the various items found in machining shops. Included 
are production machines, material handling devices, engineering workstations, 
fixtures, tooling, and raw materials, work-in-process (WIP), and finished-goods 
storage areas. Production and support personnel are modeled as well. The various 
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parts that flow through the facility can also be shown. Figure 2 presents a partial 
view of this model. 



4.1.2 Information Systems Level 

The information systems level is used to model the items and facilities used for 
executing informational activities. Two models are employed. 

The information systems model contains three-dimensional models of computers, 
monitors, printers, plotters, communications networks and various peripheral 
devices (bar code scanners, etc.). Electronic documents and messages travel on 
communications links, which are modeled as U-shaped channels, pipelines, or 
wires. The pipelines represent network connections between the computers in the 
engineering department, shop management offices, product data management 
(PDM) system, database management systems, shop machinery, and the shop floor. 
Data document icons move along the pipelines to illustrate data transfer among the 
different systems. The monitors show the interfaces to the various software 
applications employed. 




Figure 2 Partial view of physical processing systems model. 

The software applications model shows the software applications resident on 
each computer system in the facility. Applications considered at this point include 
those used for design and analysis, process planning, numerical control (NC) 
programming, machine control, scheduling, shop floor data collection, tool 
management, inventory control, product data management, order entry, and 
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shipping and receiving. The applications are represented as various artifacts: 
manuals, flowcharts, application output (e.g., graphic display), etc. 

4.1.3 System Architecture Level 

The system architecture level is used to model the functional architecture of the 
manufacturing system. A single set of models is employed, the manufacturing 
activity models. These are IDEFO models of the various activities and processes 
used in manufacturing facilities, based upon the System Integration for 
Manufacturing Applications (SIMA) Reference Architecture (Barkmeyer et al, 
1996). Activity model nodes are located under the appropriate physical or 
information system where the activity is carried out. 

Figure 3 shows the virtual manufacturing system comprised of VRML models as 
described above. 




Figure 3 Virtual Manufacturing System comprising of VRML models. 
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4.2 Application Scenarios 



To demonstrate the applicability and utility of the proposed approach, various 
scenarios are being developed. Scenarios are different manufacturing 
problems/questions for which solution information would be obtained via the 
VRML modeling environment and system models. A variety of scenarios are under 
investigation at present. Three examples are as follows. 

Scenario #1: Determination of Activities Performed at Machines 
Each machine in the facility performs a variety of processing activities. In order to 
establish which activities are performed by which machines, the activities must be 
mapped between the physical and functional views. This is done by using hot links 
at the physical processing systems level. Clicking on a machine in the physical 
processing systems model pops-up the functional activities (IDEFO nodes and/or 
diagrams) which are performed at that machine. 

Scenario #2: Identification of Equipment and Applications Associated with 
Item Production 

In order to analyze production flow in the shop, it is necessary to know what 
products follow which routes in the facility, machine utilizations, supporting 
information requirements, etc. This information can be provided via hot links, 
visibility, billboards, and overlaying of information. Clicking on a part in the 
physical processing systems model pops-up the product’s route sheet (possibly via 
a menu of selections). At the same time, the visibility of all machines not on the 
part’s routing is turned off. A set of directed arcs appears, superimposed over the 
facility (in three-dimensional space) to show the routing, with arc color, thickness, 
etc. showing the proportion of flow intensity accounted for by that product. 
Billboards appear over each machine on the routing, showing the capacity required 
for production of that product, required NC programs, etc. By cruising through the 
facility, the user can study what is required to produce the product in the facility. 

Scenario #3: Analysis of Information Flows 

A large variety and amount of information is required to support the manufacturing 
process. This information flows between various pieces of equipment (servers, 
computers, databases, NC controllers, etc.) during the production process. The 
user can study the flow of information by moving to the information systems level 
and clicking on a button to “start” the production process. Animation is then used 
to show the flow of information (documents, parameters, code, etc., represented via 
various artifacts) through the various communications channels and media (e.g., 
pipelines). 
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5 CONCLUSION AND FUTURE REASEARCH 



There is a clear consensus among researchers that an open environment is needed 
for manufacturing systems modeling. VRML appears to be an excellent candidate 
for satisfying this need. Even though it is not as powerful as some other languages, 
it does provide many features which are lacking in other environments, and is well- 
suited to the requirements of manufacturing systems modeling. VRML 1.0 was 
restricted to representing static 3D worlds. VRML 2.0 offers several improvements 
and can be used to represent dynamic environments. 

This research is an on-going effort to provide an environment for integrating the 
various views and models used in manufacturing systems modeling. Work is being 
planned to develop an interface where the user will be able to interact with the 
system in a high-level language. Additionally, work is being carried out to develop 
the capability to perform simulations in VRML worlds. 

Work described in this paper was sponsored by the NIST Systems Integration for 
Manufacturing Applications (SIMA) Program. No approval or endorsement of any 
commercial product by the National Institute of Standards and Technology is 
intended or implied. The work described was funded by the United States 
Government and is not subject to copyright. 
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Abstract 

This paper describes the architecture and concept of operation of a Virtual Reality- 
Enhanced Integrated Process Design Environment (VR-IPDE), a novel architecture 
for effectively applying Virtual Reality (VR) technology in the context of 
manufacturing system design. 

Virtual Prototyping (VP) and Simulation Based Design (SBD) have been used 
with increasing success to apply Virtual Reality (VR) for the design and evaluation 
of complex systems on a computer. VP and SBD eliminate the need for building 
expensive ‘real’ prototypes and allow for design and analysis, using computer 
based techniques, at comparable levels of fidelity. In spite of their early promise, 
several technical and pragmatic barriers have hindered the successful integration of 
VP/SBD with other manufacturing systems design methods and tools. These 
barriers include: 




1. The semantic gap between different ‘role types’ (domain experts, systems 
engineers, and developers) involved in the VP-enabled manufacturing system 
design life cycle. The result of this gap is a loss in communication and, 
consequently, significant inefficiencies. 

2. The diversity of methods, tools, and technologies that are available inhibits a) 
re-use of data/knowledge across multiple technologies, b) inter-operation of 
applications, and c) consistency maintenance across applications. 

3. The absence of structured, standard methods that describe/prescribe how to 
effectively combine the techniques and tools from VP/SB D with other 
manufacturing systems design methods and tools. 

The VR-IPDE was designed to address these problems. VR-IPDE allows 
systems designers to 1) define and characterize systems design goals and 
performance metrics, 2) develop conceptual designs of the manufacturing system 
processes and products, 3) analyze manufacturing processes using a novel 
combination of qualitative, quantitative and (VR-based) immersive analysis 
techniques, and 4) integrate manufacturing system process models and product 
models. VR-IPDE facilitates the integration of process and product models with 
VR-based immersive process analysis techniques. 

Key VR-IPDE benefits include a) reduced time and cost for designing 
manufacturing systems, b) reduced time and cost for maintaining manufacturing 
systems, c) increased mission readiness through increased system availability 
(through faster maintenance), and d) increased life cycle re-use of system behavior 
knowledge. Important application of VR-IPDE include a) Simulation Based 
Design and Virtual Prototyping, b) Augmented Reality Operations and 
Maintenance, and c) VR-enhanced Training. 

Keywords 

Simulation Based Design, Virtual Prototyping, Integrated Product Process Design, 
Engineering of Complex Systems 



1 INTRODUCTION 

The magnitude and complexity of today’s advanced commercial and military 
systems have increased so much that existing system design methodologies and 
tools are not able to provide efficient support for the design and development of 
these large, complex systems. The recent advancement of Virtual Reality (VR) 
technology (Burdea, 1994) and, in particular, the use of VR for Virtual Prototyping 
(VP) and Simulation Based Design (SBD), has created a unique opportunity for 
designing and developing large, complex systems. VP involves the use of VR and 
other advanced engineering methods for the design and evaluation of complex 
systems on a computer, thus eliminating the need for building expensive, ‘real’ 
prototypes. The use of computer-based techniques (‘virtual’ prototyping) allows 
for design and analysis at comparable levels of fidelity. SBD subsumes VP by 
employing VP models in the use of computer simulation techniques for system 
design (Karangelen, 1994; Jons, 1994). 
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The distinguishing characteristics of VP and SBD are the use of immersion and 
interaction-nQ^ paradigms in human-computer interaction. These characteristics 
allow the designer to be sensorially (sight, touch, sound, smell, etc.) immersed, 
using a combination of hardware and software technologies, in the system being 
designed. These characteristics make a VR-based human-computer interface a 
more effective, convenient, and realistic mechanism for representing and 
displaying the virtual prototype and virtual environment than other interface 
technologies. 

This paper describes the architecture and concept of operation of a Virtual 
Reality-Enhanced Integrated Process Design Environment (VR-IPDE), a novel 
architecture for effectively applying VR technology in the context of system 
engineering. Although researchers have been aware of the opportunity to apply VP 
and SBD in systems engineering for several years (Jons, 1994), little has been done 
at the research or application level to realize a successful marriage of these two 
areas. There are several technical and pragmatic barriers that hinder the integration 
of VP/SBD with the Engineering of Complex Systems (ECS); a few salient 
examples are outlined in the following list. 

1. Semantic barriers and communication inefficiencies: A central problem with 
the integration of VP and ECS is the semantic gap between different ‘role 
types’ involved in the VP-enabled, ECS life cycle processes: Domain 
experts/end users articulate needs and requirements; systems 
engineers/knowledge engineers refine and flow down requirements and 
perform conceptual/detailed design explorations; and software/hardware 
engineers and programmers perform implementation design, prototyping, and 
code refinement. Our experience has shown that the semantic gap between the 
background knowledge that each of these role types brings to the table imposes 
significant communication requirements that result, subsequently, in significant 
communication losses and inefficiencies. Technology integration is a key 
approach to addressing this problem. 

2. Disparate tools and technologies: ECS and VP integration is hindered by the 
diversity of methods, tools, and technologies that are available (and the rapid 
emergence of new innovative tools in these areas). In contrast, there is a 
corresponding absence in mechanisms that facilitate re-use of data/knowledge 
across multiple technologies (e.g., data models developed in CASE tool are not 
readable by VR modeling tools), the interoperation of applications (e.g., a HLA 
simulation tool cannot communicate with a shop flow control simulator), and 
consistency maintenance (e.g., changes made to a functional model reflecting 
changes in system requirements cannot be automatically propagated to implied 
changes in the product design model in the VP environment). 

3. Lack of methods and standards: A significant problem is the absence of 
structured, standard methods that describe/prescribe how to effectively 
combine the techniques and tools from SE and VP. Consequently, organizations 
are required to repeatedly invent new methods for combining VP with SE. 
Because of the lack of standardization, there is limited re-use of 
information/knowledge transfer between different efforts within the same or 
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different organizations. 

The VR-IPDE was designed to address each of these problems as outlined in the 
remainder of this paper. Section 2 describes the VR-IPDE architecture and Section 
3 describes the VR-IPDE concept of operation. Section 4 summarizes the 
significance of the research and outlines potential applications. 

2 VR-IPDE ARCHITECTURE 

The VR-IPDE architecture is shown in Figure 1. 




Figure 1 The VR-IPDE Architecture. 

The main VR-IPDE components are described in the following list. 

• Process Template Library (PTL): A repository of process knowledge that 
facilitates the rapid creation of process specifications and enables the re-use of 
this knowledge across a wide range of design application situations. 

• Process Template Selection Assistant (PTSA): The PTSA helps the systems 
engineer select a ‘good’ starting template for process design. The prototype 
PTSA implementation supports a simple keyword-based search capability 
based on key process characteristics including Process Type, Process 
Objectives, Outputs, and Resources. 

• Process Construction Workbench (PCW): The PCW is a process modeling tool. 
The current PCW implementation is a subset of KBSFs ModelMosaic'^^ 
environment (Pillion et. Al, 1997), an integrated systems engineering toolkit 
that supports enterprise engineering-object, process, function, and data 
modeling; ModelMosaic™ also supports enterprise analysis techniques such as 
activity based costing, project planning and scheduling, and simulation. The 
PCW supports the IDEF3 process description capture method (KBSI, 1995), an 
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emerging DoD and industry standard for process modeling. 

• Qualitative Process Analyzer (QPA): The QPA is a knowledge based assistant 
for qualitative process analysis. It is a rule-based system that assists in 
diagnosing consistency and completion errors in a given process specification 
and suggesting alternative redesign strategies. The QPA is based on the Process 
Integration and Design Toolkit (Benjamin et. Al, 1997). 

• Automatic VR Behavior Script Generator: VR behavior scripts are 

automatically generated from IDEF3 -based process descriptions. Information 
about activities, events, the temporal and logical constraints between activities, 
and the objects that participate in these activities (agents, resources, artifacts, 
etc.) are extracted from the IDEF3 -based model and converted to VR behavior 
scripts. The VR-IPDE prototype generates Graphic Simulation Language 
(GSL) scripts that are interpretable by ENVISION/EGRO’^^, a COTS VR 
system from Deneb Robotics, Inc. 

• Immersive Process Detailer (IPD): The IPD lets users immersed in a virtual 
environment perform activities specified in an IDEF3 process model. The 
user’s body motion is traced and the recorded data is used to generate detailed 
motion control data for popular COTS human modeling tools. 

• Immersive Process Analyzer (IPA): The IPA immerses the user in a virtual 
prototype to check for process design requirements, performance goals (e.g., 
visibility, accessibility, tool sweep, safety, etc.), and process design 
expectations specified in a process model. Problems that are discovered 
through immersive analysis are used to further improve the process. 

• Quantitative Process Analyzer (QNPA): The QNPA interprets the output of the 
VR simulation executions (from IGRIP/ERGO), computes different 
performance metrics, and presents the results in a form that is meaningful to the 
decision maker (systems engineer/domain expert). Performance metrics 
computed by QNPA include cycle time, idle time, and collision statistics. 

In summary, VR-IPDE provides an integrated process-modeling environment in 
which system-level, qualitative process descriptions are integrated with the 
detailed, quantitative process descriptions. The abstract, qualitative process 
description is captured by KBSFs IDEF3 process modeling tool and used to guide 
the Immersive Process Detailer (IPD). IPD employs VR technology to immerse the 
user in the virtual environment to enact the process specifications. Detailed body 
motion data (e.g., physical location and orientation of head, hand, limbs, torso, 
etc.) that is generated while performing an activity is captured in IPD and used to 
generate motion control data for human models. An important advantage of VR- 
IPDE is that it provides a more effective and robust process design and evaluation 
environment. In VR-IPDE, process performance is analyzed at the qualitative, 
quantitative, and immersive levels. The abstract process model (e.g., an IDEF3 
model) is analyzed by the knowledge-based qualitative process analyzer (QPA) to 
detect problems early in the life-cycle of a process design — when detailed, 
quantitative process information is still not available. QPA is used to determine a 
set of candidate process models for which detailed process specifications are 
constructed by the IPD. More detailed process performance is obtained by 
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executing a 3D animation/simulation model (e.g., a IGRIP/EGRO model) and 
analyzing the simulation results using the Immersive Process Analyzer (IPA) and 
the Quantitative Process Analyzer (QNPA). 



3 CONCEPT OF OPERATION FOR COMBINING SE TOOLS WITH 
VRWP TOOLS 



This section presents a characterization of the activities performed by the 
envisioned VR-IPDE end user to effectively apply the VR-IPDE tools for VR- 
enabled process engineering. This characterization, referred to as the VR-IPDE 
Concept of Operation, is sketched in Figure 2. The VR-IPDE concept of operation 
prescribes a systematic method for using different systems engineering and virtual 
prototyping tools synergistically and in combination through life cycle activities in 
the engineering of complex systems. 
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Figure 2 Concept of Operation of the VR-IPDE. 

Consider the following usage scenario. Suppose a systems designer would like to 
design the maintenance process for a weapon system virtual prototype. Figure 3 
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shows the static model of the weapon system virtual prototype under consideration. 
The system designer would like to evaluate two scenarios using this virtual 
prototype, the ‘regular maintenance scenario’ and the ‘fire-fighting scenario.’ 




Figure 3 Static Model of a Weapon Room Virtual Prototype. 



The following is a description of a possible sequence of steps performed by a 
system designer and the functions performed by the VR-IPDE in response to these 
user tasks. 

1. Process template selection: The VR-IPDE provides a library of re-usable 
process templates to facilitate the rapid assembly of process specifications. To 
construct a maintenance process of a weapon system, suppose that the user 
selects a maintenance process template of an existing weapon system as the 
starting point. Similarly, in order to construct a fire-fighting process design, the 
user selects a fire fighting process template from the template library. 

2. Process construction: Using the process templates, the system designer goes to 
Process Construction Workbench (PCW) to modify process templates and 
construct a new maintenance process. Using the PCW, the user will be able 
merge the fire fighting process template with the ‘normal’ maintenance process 
to construct a ‘fire-fighting during maintenance’ contingency situation. 

3. Qualitative process assessment and refinement: After finishing the construction 

of a process model, the next step is to diagnose consistency and completeness 
errors in the model. The system designer will execute QPA to performing rule- 
based qualitative analysis of the process models, and use the analysis results to 
refine the process models. 

Figure 4 shows sample screens from the QPA. 
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Figure 4 Qualitative Process Analysis. 



4. Automatic VR behavior script generation: Once the completeness and 
consistency errors have been eliminated, the process model is syntactically and 
semantically correct. VR behavior scripts are then automatically generated from 
the qualitative process description. Figure 5 shows a screen display during the 
conversion. The VR-IPDE generates GSL (Graphic Simulation Language) scripts 
for ENVISION/EGRO^J^, a COTS VR system from Deneb Robotics, Inc. 




Figure 5 Automatic VR Behavior Script Generation. 
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5. Product-Process model integration: At this step the user will integrate the VR 
behavior scripts (generated from the previous step) with the static product 
models to produce (virtual) system models. The VR behavior scripts describe 
the dynamic behaviors of the system; the product model describes the static 
characteristics of the system. 

6. Immersive process detailing: To specify detailed body motion for process 
activities, the user will be immersed in the virtual prototype and actually 
perform the activities. The user’s body motion data is traced to a log file. After 
adjusting for measurement distortions, the recorded data in the log file is used 
to generate detailed motion control data for COTS human models. The human 
model considered in VR-IPDE is the ERGO ‘Worker’ from Deneb Robotics, 
Inc. 

7. 3D simulation model execution: The complete VR simulation model 
constructed in previous three steps is now executed. The VR simulation used in 
VR-IPDE is ENVISION/EGRO^^, a COTS VR system from Deneb Robotics, 
Inc. Figure 6 shows the screen displays during the simulation. 




Figure 6 Virtual Reality Simulation. 



8. Immersive process analysis: During the process simulation, the user can 
immerse himself/herself in the virtual environment and check for process 
design requirements, performance goals (e.g., visibility, accessibility, tool 
sweep, safety, etc.), and expectations specified in a process model. Problems 
found during immersive analysis will be used to further improve the process. 

9. Quantitative process analysis: The results of the simulation are compiled and 

analyzed using quantitative methods. The trade-off analysis results are used to 
further refine the system design. 

Figure 7 shows screen displays generated from the quantitative process analysis. 
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Figure 7 Quantitative Process Analysis Results. 



At this stage, if the system designer is satisfied with the simulation results, then 
the process design is finished. Otherwise the system designer may go back to the 
process construction workbench to initiate another process design cycle. 

4 SUMMARY 

This paper described a novel approach to and corresponding architecture (VR- 
IPDE) for the virtual reality-enhanced process engineering of complex systems. 
The VR-IPDE applies the Air Force IDEF3 process description method and the 
emerging human-computer interaction mechanisms provided by VR technology to 
achieve an integrated process design and analysis environment. System and 
enterprise level abstract qualitative processes are integrated with the fine-grained 
quantitative process information required for high fidelity process analysis and 
evaluation. 

The proposed template based approach to complex process design significantly 
reduces the time and effort needed to design a process and increases the quality of 
the resulting processes. The combination of qualitative and immersive process 
analysis delivers higher quality first-time designs. As a result, application of VR- 
IPDE significantly reduces the life cycle system cost and risk, and increases life 
cycle system performance. The resulting designs, because the maintenance and 
operations processes (including failure modes and exceptions) were successfully 
‘debugged’ during the design phase, are more maintainable and have fewer 
operational problems. By making integrated VR-enhanced models available to 
operations and maintenance personnel, the system can be operated more effectively 
(for example, by using the VR-models of the maintenance process for doing 
‘augmented-reality’ diagnosis and repair). 

A VR-IPDE has been implemented and successfully demonstrated on a 
constructed Navy application problem situation. We anticipate many important 
VR-IPDE military and commercial applications including 1) simulation based 
design and virtual prototyping, 2) augmented reality operations and maintenance, 
3) VR-enhanced training, and 4) automatic generation of electric maintenance 
manuals. 
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Abstract 

The Technologies Enabling Agile Manufacturing (TEAM) program enhances 
industrial capability by advancing and deploying manufacturing technologies that 
promote agility. TEAM is leveraging the expertise and resources of federal 
agencies, private industry, and universities to develop, integrate, and deploy leap- 
ahead technologies. TEAM has developed a product realization process that 
features the integration of product design and manufacturing groups, highlighted 
by optimization of product, process, and resource design parameters. 

The TEAM Web Integration Manager (WIM) tool was developed to integrate 
this product realization process for the September 1997 integrated material 
removal demonstration, which featured the fabrication and inspection of a General 
Motors V8 cylinder head. The WIM provides comprehensive Web-based 
management of requirements, product attributes, process attributes, resources, and 
users. It managed the completion of process tasks from requirements definition 
through fabrication and inspection, ensuring controlled access to consistent design 
and manufacturing information. In addition, a specialized user interface into the 
WIM was deployed to provide detailed Web-based integration with a CAD system 
and with stress analysis, cost analysis, and optimization tools to provide a high 
level of automation in the Concept Optimization phase of the TEAM process. 
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1 INTRODUCTION 



The Technologies Enabling Agile Manufacturing (TEAM) program (Neal, 1995) 
enhances industrial capability by advancing and deploying manufacturing 
technologies that promote agility. TEAM is leveraging the expertise and resources 
of federal agencies, private industry, and universities to develop, integrate, and 
deploy leap-ahead technologies. TEAM has developed a product realization 
process that features the integration of product design and manufacturing groups, 
highlighted by optimization of product, process, and resource design parameters. 

The TEAM Web Integration Manager (WIM) tool was developed to integrate 
this product realization process for the September 1997 integrated material 
removal demonstration. The WIM provides comprehensive Web-based 
management of requirements, product attributes, process attributes, resources, and 
users. It managed the completion of process tasks from requirements definition 
through fabrication and inspection, ensuring controlled access to consistent design 
and manufacturing information. In addition, a specialized user interface into the 
WIM was deployed to provide detailed Web-based integration with a CAD system 
and with stress analysis, cost analysis, and optimization tools to provide a high 
level of automation in the Concept Optimization phase of the TEAM process. 

This paper presents an overview of the TEAM product realization process and 
workflow process models. The Web-based tools deployed to integrate the process 
for the product design and analysis, process planning, simulation and verification, 
fabrication, and inspection of a General Motors V8 cylinder head are then 
described. The cylinder head was the product vehicle for the September 1997 
demonstration. 

More information on .the TEAM program can be found at the URL 
http : //ce WWW . eng . ornl . go v/team/home. html . 

1.1 The Product Realization Process 

The TEAM product realization process is derived from the TEAM product 
realization model (Figure 1) and is driven by customer needs to provide solutions 
in the form of products and services. It consists of Concept Optimization, Design 
Optimization, and Execution phases. This process is based on development and 
execution of a product realization script. The script, which is produced through 
close collaboration by all of the participants in the product realization process, 
contains all of the information needed to manufacture a product, stored in a format 
that makes it usable and readily available to all who need it. It also serves as a 
repository for all information about the product and its manufacturing process. The 
information in the script is optimized by trading off critical product, process, and 
resource parameters. The script then becomes the “master” for creating product 
during the execution phase, where acquisition, allocation, fabrication, and 
assembly are conducted to produce the end products. 
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Enterprise Knowledge 





Figure 1 The TEAM Product Realization Model. 



The product realization script is based on enterprise knowledge captured from 
past experience and includes information and domain knowledge for similar 
products, product models, manufacturing processes, and enterprise resources. 
These knowledge assets are integrated through an infrastructure that enables 
collaboration by different partners and interoperability of systems and tools. 

Concept optimization is the first step in the TEAM product realization process. 
This step captures the customer’s needs and desires, converts them into 
requirements, and translates the requirements into optimized concepts in the form 
of a baseline script. This is accomplished through an iterative process of capturing 
and prioritizing customer needs, defining solutions to those needs, establishing 
target parameters for the solutions, and analyzing and optimizing these parameters 
relative to design targets. This agreement between the customers and the providers 
is documented in the form of a product design and supporting information which 
are captured in the baseline script. 

After the baseline script is in place, there is still more work to perform to create 
the detailed information needed to execute the manufacturing process. Detailed 
analyses that were not necessary to develop the initial product realization concepts 
must now be performed to optimize the designs of the product and its 
manufacturing processes. Manufacturing information that drives the factory must 
be created in the right format, and all of this information must be optimized for 
performance and cost-effectiveness. This is the Design Optimization phase, which 
translates a low-fidelity baseline script into a high-fidelity manufacturing script. 
The design optimization process involves three iterative design optimization 
environments: products, manufacturing processes, and enterprise resources. 

The Execution phase implements the manufacturing script to produce tangible 
products. Necessary information is extracted from the manufacturing script to 
operate the enterprise’ s manufacturing processes and deliver the desired product. 
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1.2 The Workflow Model 



The product realization model provides a high-level view of the strategy for 
product realization. However, the strategy must be tailored for specific product 
requirements. This is accomplished using workflow models. They bring the right 
tools at the right time to do the right job in an integrated environment of total 
product and process optimization. 

In the Concept Optimization phase (Figure 2), there is close interaction with 
the customer to capture the needs and desires and convert these into product, 
process, and resource requirements. For estimating and communication purposes, a 
parametric, features-based solids model of the product is created to identify the 
requirements, materials, and features of the product that drive its 
manufacturability, cost, and schedule. The overall deliverable from Concept 
Optimization is the baseline script, which consists of the functional requirements, 
“first cut” solids model of the product, process, and resource information, and 
design rationale. Detailed, high-fidelity decisions are deferred to the next phase in 
the process. 



Customer Needs & 
Requiremenls 



I 



1,1 Capture Fmictioual 
Requirements 



Baseline 

Script 
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1.2 Create 
Product Design 




Resources 



Performance 



Figure 2 Concept Optimization Workflow. 

Once customer needs are established to the point that the product’s 
requirements can be clearly and completely defined, the functions of producibility, 
process modeling, simulation, analysis, and resource planning are conducted, 
interoperating seamlessly and concurrently, to provide accurate assessments of 
cost, performance, and schedule for various product realization approaches. In this 
process, all options are considered in a systematic way, not just to evaluate the 
impact of individual operations, but to assess their interaction with all other 
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operations. This ensures that the best decisions are made. These processes enable 
the rapid tradeoffs of key factors so that an optimized, validated design may be 
determined for the product and its design and manufacturing processes. 

This is all part of the Design Optimization phase (Figure 3). Simulation and 
optimization tools take the baseline script to the next level of detail to fine tune the 
best methods, materials, and processes for manufacturing execution. The 
manufacturing script is prepared during this step. The manufacturing script is the 
total package of information required to produce the product accurately, 
efficiently, on time, and within budget. It consists of the solids model, operations 
process plans, validated part manufacturing and inspection programs, and 
supporting work instructions. 



n 

Baseline 

Script 





Figure 3 Design Optimization Workflow. 

The Execution phase (Figure 4) of the product realization process is where the 
information generated by the process is put to use in making product. In this phase, 
intelligent closed-loop manufacturing processes are performed with 100% 
assurance of a quality result. Such certainty is possible because control models are 
in place for each process and the parameters of each model are supplied in the 
manufacturing script for every product. The process control models are the result 
of a systematic process called deterministic manufacturing. This means that 
processes are characterized by defining all of their parameters, quantifying their 
interactions and impacts on process performance, defining cost and performance 
tradeoffs to define control limits, and developing monitoring and control strategies 
to ensure correct execution. 
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Figure 4 Execution Workflow. 



2 EXECUTION OF THE WORKFLOW 

Integrated product realization demands a control mechanism. With the increasing 
importance of geographically distributed enterprises, TEAM is developing Web- 
based tools to manage this extended enterprise. Internet access to tools and 
information is a must in managing today’s distributed, agile, virtual enterprises. 
Internet access provides multi-platform support that allows diverse users to 
participate in a distributed enterprise using their existing computer hardware, 
software, and networks. Therefore, the focus of TEAM integration activities for 
the September 1997 integrated material removal demonstration was the integration 
of this environment. The demonstration featured implementation and execution of 
the integrated TEAM product realization process for a General Motors V8 engine 
cylinder head. 

This implies that an environment must be created that integrates all the tools in 
a process workflow that understands the concept of “attributes.” Features of this 
integrated environment include: 

• the tools required to execute the workflow must all interoperate; 

• all data conversions must be done in the background, without user 
intervention; 

• a common user interface (for the workflow but not necessarily for each 
individual tool); 

• the ability to link requirements to product attributes; 

• the ability to execute any part of the workflow from any location. 
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The user starts by defining the process and its attributes. A process is made up 
of a series of tasks and transitions between the tasks and must be presented 
graphically to users. For each task, the following information must be entered: 

• who can perform the task (based upon qualifications and access to 
resources); 

• inputs (may be files and/or attributes); 

• outputs (may be files and/or attributes); 

• resources to transform inputs into outputs; 

• transitions to other tasks. 

Based on the identified customer needs, requirements are captured. 
Requirements may be updated during execution of the product realization process 
as necessary. Based on experience and engineering judgment, the user selects 
product attributes that are needed to evaluate the product design. Some product 
attributes are relatively simple, such as dimensions, tolerances, and material types. 
Other product attributes are summary values from complex analyses, such as 
maximum stress in the part. Once selected, the user enters the product attributes 
into the enterprise knowledge system. It is expected that product attribute values 
will be updated throughout the product realization process as an optimal design is 
determined by iterations through the process. Updated values may also be 
imported from resources invoked to perform design tasks. In addition to the 
product attributes, each task in the TEAM workflow model has process attributes 
that must be defined and entered. Input process attributes represent the information 
needed by a task to perform the required task functions. Output process attributes 
can feed downstream tasks in the workflow model or provide process 
characterization data used for future jobs. After requirement, product, process, and 
user information is populated during execution of the product realization process, 
the baseline script and manufacturing script information are available for review, 
revision, and subsequent execution. 



3 THE FRAMEWORK 

Integrated product realization means that all of the tools in the total manufacturing 
effort work together in a “seamless” fashion where all information is available in 
the right form to all applications that need it. In the perfect solution, all systems 
and tools would comply with universally accepted standards. This is not the case 
today, nor is it soon likely. Therefore, we must adopt an integration framework as 
a liaison between all of the different systems and multiple protocols which allows 
our tools to communicate. An integration framework is a software infrastructure 
(common objects, common services, and interfaces) that creates a common 
environment for integrating applications in “plug and play” fashion and sharing 
information across different computing platforms and operating systems. 
“Wrappers” and translators associated enable diverse tools to interoperate within 
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the enterprise. TEAM has provided such an integration framework for its product 
realization process with the Web Integration Manager and the Conceptual Design 
cockpit as discussed below. 

3.1 Web Integration Manager 

Integrated product realization requires a control mechanism to manage the product 
realization process over the Internet based on enterprise product, process, and 
resource information. For TEAM, the mechanism must manage the completion of 
tasks comprising the Concept Optimization, Design Optimization, and Execution 
phases of the TEAM product realization process to ensure access to consistent and 
up-to-date design and manufacturing information. As tasks are performed, the 
script is developed and information is fed back into the enterprise. All information 
necessary for every task is managed in a secure and controlled environment. 

The Web Integration Manager (WIM) was the focus of TEAM integration 
activities for the September 1997 integrated material removal demonstration. The 
demonstration featured implementation and execution of the TEAM product 
realization process for a GM V8 cylinder head under control of the WIM. The 
WIM provides comprehensive Web-based management of requirements, product 
and process attributes, resources, and users. It coordinates execution of the defined 
process by providing elements of workflow and by invoking tools to perform each 
step in the process. Any process, using any tools, can be modeled and managed by 
the WIM. From this point forward, however, for example purposes it is assumed 
that the defined process is the TEAM product realization process as defined by the 
workflow models presented in Section 1 . 

For the September 1997 integrated material removal demonstration, TEAM 
moved from file-based integration to attribute-based integration. Attribute-based 
integration allows requirements, product models, and process models managed by 
the WIM to be linked to information managed by resources external to the WIM. 
For example, WIM product model information is currently linked to selected Pro/E 
dimensions. This enables tighter integration than is possible with file-based 
integration. Linkage of requirements to product and process attributes is achieved 
since all of the information is managed in one application. Since it is not realistic 
to eliminate files as a mechanism to share information between diverse 
applications invoked by the WIM, the WIM does provide file storage and retrieval 
capabilities needed to execute process tasks. 

Requirements 

The user can enter requirements directly into the WIM, which provides a logical 
hierarchy of requirements. It is also possible to import requirements from a 
requirements management tool, although this requires the integration of the WIM 
and the specific tool. Similarly, requirements created in the WIM can also be 
exported to a requirements management tool. Requirements entered directly into 
the WIM may be updated during the product realization process. 
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Product attributes 

Product attributes are used to define the subject part. Typical attributes include 
dimensions, tolerances, material types, and performance parameters such as cost 
and miles per gallon. The WIM provides a hierarchical organization of product 
attributes. Like requirements, product attribute values may be entered directly into 
the WIM by the user. These values may also be imported from and exported to 
external resources such as CAD systems. Again, this requires the integration of the 
WIM and the particular external resource. 

Many product attribute values will be updated throughout the product 
realization process as the design is optimized through multiple iterations. These 
updates may be performed directly by the user via WIM input screens. Updated 
values may also be imported from resources invoked to perform design tasks. 

Process attributes 

A process consists of a series of tasks and the transitions between the tasks. The 
WIM provides a hierarchical organization of process steps to support navigation 
through the process. Each WIM task has associated with it who can perform the 
task, inputs needed to perform the required task functions, outputs fed to 
downstream tasks in the workflow model, and resources used to perform the task 
functions. 

User information 

Users must request access to the WIM using the Create_User WIM service. User 
input includes a login username and password and administrative information such 
as an e-mail address for notifications. After a user’s access request is authorized, 
he or she may then log in to the WIM using their specified username and 
password. 

Execution of the Process 

After requirement, product, process, and user information is captured in the WIM, 
the WIM can be used to coordinate and manage execution of the product 
realization process. Users log in to the WIM and select the specific project to be 
reviewed or updated. Requirement, product, and process information can each be 
reviewed in detail. A list of pending tasks that the user is expected to complete is 
maintained based upon the completion of previous process tasks and task 
transitions. To participate in the process, the user selects a task from his or her list. 
For each task performed in the process, the following steps occur: 

• When a task is selected, all defined task inputs (files and attributes) are 
delivered to the user. 

• The user invokes resources from the list of defined task resources and uses 
the resources to complete activities for the task. 

• When the user indicates completion of the task, 1) all defined task outputs 
(files and attributes) are delivered to the WIM for use in downstream tasks, 
2) pending task lists are updated based upon tasks that can now be initiated. 
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and 3) users whose pending task lists are updated are notified that they can 
now initiate a task. 

When the entire process is completed, the baseline script and manufacturing script 
information reside in the WIM and are available to the enterprise for execution. 

3.2 Web Aided Engineering 

A reality in moving from the way we do business now to the way we will do 
business in the future is the challenge of integrating existing “legacy” systems. In 
the TEAM process, tools are provided which interface with systems not readily 
compatible with current-generation “open” hardwai'e and software. 

Web Aided Engineering (WAE) integrates services with the WIM by linking 
WIM information to information managed by legacy systems. WAE translators, or 
“gateways,” provide access to the legacy systems without requiring users to have 
those systems loaded on their machines. WAE gateways take advantage of the 
robustness of those systems, turning them into WAE services. For the September 
1997 integrated Material Removal demonstration, WAE gateways were created for 
Pro/E, the FElt stress analysis tool, the CostAdvantage cost and manufacturability 
analysis tool, and the Sandia National Laboratories DAKOTA optimization tool, 
each of which was featured in the Concept Optimization phase. 

When a WAE gateway from the WIM is created in conjunction with a 
“wrapper” (software that provides a defined interface to access services) around 
the legacy system, the WIM user has access to needed legacy system information 
without having to navigate screens associated with that system. This enables 
automation when coupled with front-end user interfaces to the WIM. A gateway 
and a wrapper are both required to provide import/export of legacy system 
information to and from the WIM. 

3.3 Conceptual Design Cockpit 

Integrated product realization, with its systematic approach to manufacturing, 
opens the door for knowledge-based systems and automated information 
generation. TEAM has focused its knowledge automation efforts, as a first step, on 
the Concept Optimization phase with a “cockpit” for conceptual design. The 
cockpit allows the customer to make choices about what he or she wants and then 
quickly and “automatically” see the results of those choices. 

Where WAE services extend the back-end capabilities of the WIM, cockpits 
extend the front end. A cockpit is simply a specialized user interface to the WIM 
that enables users to easily perform some subset of process activities in an 
automated manner. For the September 1997 integrated Material Removal 
demonstration, a Conceptual Design cockpit (Figure 5) was provided to allow a 
single conceptual designer to perform iterative design tradeoff studies in real time 
using the Conceptual Design tools listed in the previous section once the stress 
analysis, cost analysis, and optimization problems were defined and set up by 
domain experts. When used with WAE gateways, cockpits provide a high level of 
automation. 
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Figure 5 Conceptual Design Cockpit. 



4 NEXT STEPS 

In 1996, TEAM demonstrated the use of product realization and workflow models 
for manufacturing. In 1997, we added a richer toolset and integration. There is still 
much to do as we pursue the goal of building a rich manufacturing technology 
infrastructure that will serve us well into the next century. In 1998, each of the 
participating Department of Energy TEAM sites will apply TEAM tools and 
processes to local projects and will present demonstrations highlighting the 
projects and the impact of TEAM program deliverables on successful completion 
of the projects. 

The Oak Ridge Y-12 Plant will apply TEAM tools to a project featuring the 
production of a mastering part for dimensional inspection and scheduling of other 
products manufactured in the same facility. Project tasks comprise a subset of the 
TEAM product realization process described in Section 1. Processes to be 
addressed include turning, milling, and dimensional metrology. Production 
activities including product design, process planning, simulation, numerical 
control part program creation and verification, detailed work instructions, 
machining, and inspection will be performed for the mastering part. Shop floor 
control activities including schedule forecasting and consolidation, tracking of 
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individual products along their routing, and documentation management for shop 
floor activities will also be demonstrated. 

The demonstration will be achieved in an integrated environment, supported by 
the WIM. WIM enhancements to be delivered in support of this project include 
migration to a Windows 32-bit platform, integration with a commercial object- 
oriented database, configuration management and access control enhancements, 
support for tracking and scheduling of multiple products, and an improved WIM 
modeling user interface. Integration with a project planning tool will facilitate 
cost, schedule, and resource availability tracking. 
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Abstract 

The SEMATECH CIM (computer integrated manufacturing) Framework defines 
an industry standard framework for semiconductor manufacturing information and 
execution systems (MIES). The CIM Framework architecture defines an object- 
oriented software component architecture building on CORBA and CORBA 
services specifications from the Object Management Group. Using this 
architecture, the CIM Framework Specification defines an application mode that 
specifies the interfaces and behavior of functional software components for MIES. 
There are component definitions for machine control, material movement, material 
management, process specification management, advanced process control, factory 
operations, dispatching, and labor management. Standard interface and behavior 
specifications for these MIES functions enable manufacturers to assemble and 
evolve manufacturing systems using components from different suppliers, in- 
house development or legacy systems. In early 1998, SEMI Standards, the 
semiconductor industry standards organization, will ballot the CIM Framework for 
adoption as provisional standards. This paper provides an overview of the CIM 
Framework architecture and illustrates the form and content of the application 
models in the CIM Framework. 
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1 INTRODUCTION 



Flexible manufacturing information systems are essential to manufacturing agility 
and competitiveness (Holland et.al., 1996; Hawker et.al., 1996a). Manufacturers 
must be able to modify, upgrade and enhance their manufacturing information and 
execution systems (MIES) with new functions and technologies that meet their 
changing business needs (SIA, 1997). However, most MIES available and in use 
today are monolithic systems where it is very expensive, in time and money, to 
integrate new functions or to upgrade technologies (Aardal, 1994). There are 
significant, often unacceptable, time and cost barriers to building new systems and 
enhancing current systems, resulting in the risk of not having the MIES that enable 
competitive manufacturing. 

The SEMATECH CIM Framework addresses the needs for semiconductor 
manufacturers to, over time, assemble MIES software components from multiple 
suppliers into an integrated MIES system that meets their changing business needs. 

SEMATECH CIM Framework 

SEMATECH, a research and development consortium of semiconductor 
manufacturers, has just completed a strategic program to defme a framework for 
integrating MIES applications. This framework, the CIM Framework defines a 
standard application model of MIES applications (Hawker, 1996; Doscher, 1997; 
Doscher, 1998). The application model defines standard interfaces and behaviors 
for parts (components) of applications that are common across applications. It 
leverages distributed computing technology standards from the Object 
Management Group (OMG) (OMG 1995, 1996, 1997) to enable integration of the 
applications. Manufacturers that implement MIES systems based on the CIM 
Framework can incrementally build MIES by integrating applications from 
multiple suppliers, and they can upgrade these systems with evolving distributed 
computing technologies conformant with OMG standards and with application 
component functions and technologies conformant with CIM Framework 
standards. The CIM Framework defines a standard MIES software component 
architecture and application component interfaces. It enables semiconductor 
manufacturers to significantly reduce the cost and time required to build, modify 
and enhance their MIES in response to changing business needs. 

Industry consensus 

SEMATECH led an industry consensus process to develop the CIM Framework 
software component architecture and component interfaces. MIES suppliers and 
users in the semiconductor industry cooperated to develop proposals for twelve 
provisional standards which are now in review in SEMI Standards, the standards 
organization for the semiconductor industry. Many suppliers are developing and 
marketing MIES products conformant with the CIM Framework. SEMATECH 
also co-chairs the OMG Manufacturing Domain Task Force (MfgDTF) and is 
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involved in other OMG task forces which are adopting CIM Framework 
architecture and application components (OMG 1997a, 1998). 

CIM Framework standards 

The twelve CIM Framework standards ballots are based on the SEMATECH CIM 
Framework Specification (Doscher, 1998) and the CIM Framework Architecture 
Guide (Hawker, 1996; Doscher, 1997). They are an integrated system of software 
standards, but are separated so they can evolve in SEMI in response to industry 
priorities. The twelve standard proposals include three documents to describe 
goals, architecture and global definitions, plus an application model made up of 
nine groups of component interface definitions, as follows (SEMI 1998): 

• CIM Framework organization and introduction 

• CIM Framework architecture 

• CIM Framework global definitions, events and abstract base interfaces 

• Application component interface definitions 

- Factory services group - Machine control group 

- Factory management group - Advanced process control group 

Material management group - Scheduling group 

Material movement group - Factory labor group 

- Process specification group 

SEMI has three international task forces (Europe, Japan and North America) 
cooperating toward adoption of the CIM Framework standards. Further 
information is available at the following worldwide web site: 
http://semi-tf-cim-ffamework.ipa.fhg.de 

Paper organization 

This paper provides an overview of the CIM Framework software architecture and 
describes the Product Management application component to illustrate the form 
and content of the application models in the CIM Framework. Section 2 describes 
the CIM Framework application component architecture, its basis in OMG 
standards and the specification methodology the CIM Framework uses. Section 3 
describes the scope and structure of the CIM Framework application models. 
Section 4 provides a view of the Product Management component specification 
excerpted from the SEMATECH CIM Framework Specification. Section 5 is a 
conclusion. 



203 




2 



CIM FRAMEWORK COMPONENT ARCHITECTURE 



2.1 Architecture Objectives 

The CIM Framework software architecture is designed to enable integration of 
MIES applications when those applications are integrated over time from multiple 
third-party suppliers, internal development and legacy systems. The specific 
objectives of the architecture are to enable the following capabilities: 

• Interoperability - applications can cooperate by exchanging data, providing 
services (client/server method invocation), publishing service exceptions, and 
publishing and subscribing to events. 

• Substitutability - MIES implementers can replace an application from one 
supplier or source with a functionally equivalent application (conformant to 
standard interface and behavior) from another source without impacting the 
other applications. 

• Extendibility - MIES implementers can extend or specialize existing systems 
and can add new applications, application components or objects, and these 
extensions can fully use all existing system functionality. 

• Flexibility - MIES implementers can compose and configure applications in a 
variety of ways that meet specific needs. 

• Reuse - leveraging the benefits of substitutability, extendibility and flexibility, 
MIES implementers can base new systems on the design and implementation 
of standard components of applications, enabling solutions to be developed 
more quickly, at lower cost, and with higher quality. 

2.2 CIM Framework Component architecture 

The CIM Framework architecture is a layered system, as in the overview of Figure 
1 and the detail of Figure 2. The architecture enables distributed, object-oriented 
applications assembled from common software components to interoperate as a 
single, integrated system. 
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Figure 1 CIM Framework architecture layers. 

(Used with permission of SEMATECH, Inc.) 

The integration infrastructure (the bottom layer of Figure 1) is based on CORBA, 
CORBAservices and CORBAfacilities (CORBA: Common Object Request Broker 
Architecture) specifications in the Object Management Architecture (OMA) from 
the OMG (OMG 1995, 1996, 1997). CORBA, CORBAservices and 

CORBAfacilities define standard services for distributed object communications, 
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persistence, transactions, name services, etc. This defines the infrastructure 
“plumbing” for application integration. 

On top of the infrastructure, the CIM Framework architecture defines common 
application components. Components are software building blocks - “chunks” of 
functionality that make up software applications. Components are more coarse- 
grained than objects (components are defined in terms of closely-related objects) 
but more fine-grained than typical MIES applications. The CIM Framework 
common components layer defines standard models for application components 
that are common across MIES applications, such as definitions for a Machine 
Management Component (including machine resources, sensors, process 
capabilities, and relations to material and recipes), a Product Management 
Component (including product material, lots, and relations to product and process 
specifications) and a Person Management Component (including persons, 
qualifications and relations to skills and skill requirements). This common 
application model, defined in terms of common software components, is the 
framework for building integrated MIES applications, that is, the basic MIES 
application models on which all MIES applications are based. The common 
components do not define complete MIES application models, only the core 
application models that are common across MIES software applications. 

The application objects layer of the CIM Framework architecture provides 
additional functionality, extending the common components to make a complete 
MIES. This layer, which is identified but not specified, enables MIES suppliers 
and users to define product-specific and site-specific application objects and 
components that use and extend the CIM Framework common components to 
implement MIES functions that meet business needs. 
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Figure 2 CIM Framework component architecture. 

(Used with permission of SEMATECH, Inc.) 
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A given MIES application, then, implements some common components and 
application objects and interoperates (via the infrastructure) with other common 
components and application objects implemented in other MIES applications. 
Figure 2 illustrates the relationship between the infrastructure, common 
components and application objects. The collection of interoperating MIES 
applications provide a complete, integrated, MIES solution. By basing the solution 
on standard infrastructure services and standard application models for common 
MIES components, the agile manufacturer can cost-effectively build, modify and 
enhance the MIES. 

2.3 Component specification methodology 

The goal of the CIM Framework is to specify application components that MIES 
implementers can assemble into a tightly-integrated system. The high expectation 
for tight integration demands functionally rich component specifications. It is not 
enough to simply specify the syntax of component interfaces. The CIM 
Framework also specifies interface semantics and component behavior. 

The CIM Framework uses the following modeling methods to specify 
components: 

• component relationship models showing interaction between “medium- 
grained” components (larger than an object, smaller than an application); 

• component information models showing object interfaces and relationships in 
the form of OMT (Object Modeling Technique) diagrams (Rumbaugh, et.al 
1991); 

• object interface definitions using OMG Interface Definition Language (IDL); 

• published and subscribed events using an extension to OMG IDL; 

• component interaction diagrams showing scenarios that trace messages and 
events between components; 

• state transition diagrams (as Harel state charts) and state definition tables. 

These modeling methods go far toward specifying components that MIES 
implementers can “plug-and-play” into integrated systems. SEMATECH is also 
working in the OMG Business Objects Domain Task Force to define and 
standardize additional methods for even richer semantic models, including the 
specification of method pre-conditions and post-conditions, roles, rules, and 
dependencies (OMG, 1998). 
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3 



Application models 



The CIM Framework specifies application components for Manufacturing 
Information and Execution Systems (MIES). MIES perform factory operations 
functions, in the context of Enterprise Information and Control Systems and 
systems that automate material processing, storage and movement. Figure 3 shows 
the MIES functional groups in the CIM Framework. 




Figure 3 Functional groups for MIES. 



Each functional group defines a collection of related application components. 
Table 1 lists the CIM Framework components in each functional group. The 
functional groups are a convenient mechanism to organize the CIM Framework 
components; they are not rigid partitions and suppliers can deliver applications that 
span functional groups or that implement only some of the components of a group. 
In contrast, the component is the smallest-grained entity that suppliers can deliver. 
A supplier must implement all the interfaces and behaviors of a component in 
order to claim conformance to that component specification. 

The value and power of the CIM Framework is in the industry standard 
application model which specifies medium-grained components common to MIES 
applications. The SEMATECH CIM Framework Specification Version 2.0 
(Doscher, 1998) has almost 300 pages of detailed component models specified 
using the methodology of Section 2.3. Section 4 presents a portion of the CIM 
Framework Product Management component to illustrate the style and detail of the 
specification. By developing industry-wide consensus on these component 
definitions, SEMATECH has enabled manufacturers to quickly and cost- 
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effectively build, modify and enhance MIES by assembling standards-conformant 
components from multiple suppliers. 

Table 1 CIM Framework application components 



Factory Services 
Document 
Management 
Version Management 
History Management 
Event Broker 

Factory Management 
Factory 

Product Release 
Factory Operations 

Factory Labor 
Person Management 
Skill Management 



Machine Control 
Machine 
Management 
Recipe Management 
Resource Tracking 

Material 
Management 
Product Management 
Durable Management 
Consumable 
Management 
Inventory Region 
Product Specification 
Bill of Material 

Material Movement 
Material Movement 



Advanced Process 
Control 

Plugin Management 
Plugin Execution 
Control Management 
Control Execution 
Control Database 
Data Collection Plan 

Process Specification 
Management 
Process Specification 
Process Capability 

Schedule 

Management 

Dispatching 



4 PRODUCT MANAGEMENT COMPONENT 

This section presents an excerpt from the SEMATECH CIM Framework 
Specification Version 2.0 (Doscher, 1998) (used with permission of SEMATECH, 
Inc.). The component is specified using the methodology of Section 2.3. All 
capitalized and run-on words (such as ProductManager) refer to software entities 
specified in the CIM Framework. Portions in Courier font (such as 
MaterialLocation getMaterialLocation) is OMG IDL that can be 
compiled. 

Section 4.1 contains the information model (in OMT notation) for the Product 
Management Component. Since the focus is on integration, the information model 
describes only the interfaces to and relations between component objects, not the 
implementations. A given implementation may have a different object structure 
that implements the specified interfaces. The terminology is consistent with OMG 
IDL. Section 4.2 presents a portion of the IDL for the Product object’s interface. 
Section 4.3 presents the dynamic model (the states and state transitions) for 
Products as a Harel state chart in Figure 5. Table 2 provides a description of some 
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of the states and the query method for asking a Product its state, and Table 3 
provides a tabular form of some of the state chart to document the triggers and 
actions of state transitions. Only a portion of the IDL and state tables are 
presented in order to provide an introduction without too much detail. Refer to the 
CIM Framework Specification for complete models. In section 4.1 through 4.3, 
the style and content is as found in the CIM Framework Specification. 

4.1 Description and information model of Product Management 

The Product Management Component provides the representation for various 
types of product to be viewed at the factory level. Behavior concerning product 
location, product aggregation, and product progress are services provided by the 
interfaces in this component. Categories of product are wafers, die, and packages. 
The aggregation of products is represented as a lot. A ProductManager provides 
lifecycle management and coordination of behavior for objects representing 
product and lot. 

ProcessGroup represents a material aggregate used for processing in a machine. 
Units of Product or parts are known to be in a process together when they are 
members of the same ProcessGroup. This interface should be considered for 
customization to the practices of a particular Factory. 

Figure 4 contains the Product Management component informational model. 
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Figure 4 Product management component information model. 

(Used with permission of SEMATECH, Inc.) 
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This component defines the following interfaces: 



• ProductManager 

• Package 

• Product 

• Lot 



Wafer 

LotFamily 

Die 

ProcessGroup 



A portion of the Product interface definition follows. 

4.2 Product interface definition (portion) 



Interface: Product 

Inherited Interface: Material 

Description: The Product interface provides for the representation of 

any material that undergoes processing in a Factory. 

Product, in the semiconductor industry, includes any 
unit which is intended to become a functional 
semiconductor device including functional engineering 
devices. Associated with each Product is a specification 
for building it, a flow (or route) created from that 
specification, a production history, and a possible 
position in a positional container. 

Exceptions: 

/* This signal is raised when an operation assumes that a Product is in a positional 
container when it is not. */ 

exception ProductNotInPos it ionalContainer Signal 
{Product aProduct; } ; 

Published Events: None. 

Provided Services: 

/* Set and get the location of the Product. */ 

MaterialLocation getMaterialLocation ( ) 
raises ( FrameworkErrorSignal ) ; 
void setMaterialLocation 

(in MaterialLocation aMaterialLocation) 
raises 

(FrameworkErrorSignal, SetValueOutOf RangeSignal ) ; 

/* Returns the Lot of which the Product is a member. The set method has no public 
interface. */ 

Lot getLot ( ) raises (FrameworkErrorSignal); 

/* Set the Product’s status to the state indicated. */ 
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void makeNotAllocated ( ) 
raises 

( FrameworkErrorSignal, InvalidStateTransitionSignal ) ; 
/* Answer whether the status of the Product is that indicated. */ 
boolean isCreated ( ) raises ( FrameworkErrorSignal ) ; 

4.3 Product dynamic model 




Figure 5 Product dynamic model. 

(Used with permission of SEMATECH, Inc.) 
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Table 2 Product state definition and query (portion) (Used with 
permission of SEMATECH, Inc.) 



State Definitions 

Created and Not The Product is created but not 
Allocated allocated to a Lot. 

Created and The Product is created and has 
Allocated been allocated to a Lot. The 

corresponding Lot state will 
be Created. 



Query for State via 
boolean isNotAllocated ( ); 
sent to the instance of 
Product. 

boolean isAllocated ( ); 
sent to the instance of 
Product. 



Table 3 Product state transitions (portion) (Used with permission of 
SEMATECH, Inc.) 



# Current Triggers New State Action Comment 

State 



0 non- 


Wafer 


Not 


Objects of 


extensions for 


existent 


create WaferNamed ( 
in string identifier);, 
Die createDieNamed( 
in string identifier);, 
Package 

createPackageNamed( 
in string identifier);, 
sent to instance of 
ProductManager. 


Allocated 


Specific 
Product type 
are created 


new Product 
types can be 
added 


1 Not 


Lot createLotUsing ( 


Allocated 


The instance 


The instance 


Allocated 


in ProductRequest 
aProductRequest) ; , 

Lot createLotUsing 
_fromProducts ( 
in ProductRequest 
aProductRequest, 
in ProductSequence 
aProductSequence) ; , 

Lot createLotUsing 
_withldentifiers(. . . ); 
sent to ProductManager 




of Product is 
associated 
with an 
instance of 
Lot. 


of Lot that the 
Product is 
associated 
with is not yet 
placed into 
Production but 
is ready for 
Release (ready 
for going into 
production). 
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5 CONCLUSION 



The SEMATECH CIM Framework is important to the semiconductor 
manufacturing industry. It addresses growing business pressures to provide MIES 
with the flexibility and functionality that supports agile, competitive 
manufacturing. The CIM Framework is real. All major semiconductor MIES 
suppliers and many material control and process automation suppliers are working 
with many of the largest semiconductor manufacturers to review and adopt CIM 
Framework standards in SEMI Standards. Many of the suppliers have products 
which are heavily influenced by early versions of the CIM Framework, and most 
have committed to make their products CIM Framework conformant. In 1998 and 
beyond, semiconductor manufacturers will be able to replace obsolete, inflexible 
MIES with open systems built from standards-conformant components. 
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Abstract 

Three-dimensional CAD/CAM systems are generally used in manufacturing 
forging molds and dies for automotive crankshafts. Although the conventional 
process dependent on wooden models has been gradually replaced to some extent 
by an NC process with still expensive cost, another advanced process then become 
required for 3D modeling and verification of NC data since it still greatly depends 
on the skilled operator’s experience. 

In this study, examples of an automated CAD system for three-dimensional surface 
modeling with a rule-based modeling process are introduced. This uses intelligent 
CAD construction tools in crankshaft forgings and dies. 



Keywords 

Intelligent CAD, crank-shaft, modeling process, rule-based, object-oriented 
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1 INTRODUCTION 



Three-dimensional CAD/CAM systems are used in mechanical parts industries to 
define 3D geometry of automotive crankshafts. However, due to the increasing 
demand from automotive companies for lighter- weight crankshafts, the actual part 
shapes sometimes become so complicated in programming by conventional 
CAD/CAM systems that many forging vendors who use CAD/CAM often need to 
compensate unsuccessfully defined portion of 3D geometries by outsourcing them 
to old-fashioned pattern makers. Therefore, the conventional CAD/CAM process 
ironically increases the amount of hand operation as well as inflating the 
investment for computer power. 

It would be of great benefit for CAD/CAM users to automate the conventional 
process that has been relying on skilled operator’s experience. To meet this 
ultimate requirement for idealistic CAD/CAM process, we require some advanced 
software development which would significantly extend the existing technology. 

In this study, examples of an automated process of conventional CAD/CAM 
system are introduced which applies a rule-based intelligent approach in defining 
3D surface geometries for crankshaft forgings. 



2 CHARACTERISTICS OF DIE FORGING CRANK-SHAFT 

Crankshaft forging has the following characteristics: 

It is a mill product. 

Crankshaft is a built-in part of an automotive engine and is normally produced with 
mold and die making process. It is merely a “raw material” when shipping out 
from forging vendors and will be afterwards machined and ground at automotive 
companies into the final engine part. 

It is a structural part. 

The crankshaft, which cannot be seen from the outside, is designed such that it 
should only satisfy mechanical conditions required within engine; structural 
strength, vibration and noise, and spatial positioning against other parts (piston, 
con-rod etc.). While it does not need an artistically designed free form surface, it is 
usually consolidated with primitive solid geometries complicatedly blended 
together. Those primitive geometries are cylinders, cones, and other “curve-driven 
surfaces” that are defined by manipulating analytical curves in 3D space. 

In this study, three kinds of those curve-driven surfaces were chosen: extruded 
surfaces, revolved surfaces and ruled surfaces. There are other types of surface in 
defining crankshaft that is created during inserting a blending surface between 
those curve-driven surfaces. This type of blended surface is what is called “free- 
form surface”. 
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The actual shape of finished crankshaft which is ready to be assembled within 
engine mainly has such kind of curve-driven surfaces and dose does not contain 
many free- formed surfaces. However, as-forged crankshafts have many kinds of 
draft surfaces and blended surfaces (free-formed surface) this consequently make 
3D modeling still more difficult. 



3 CAD SYSTEM NEWLY DEVELOPED 

The following items have been considered in developing the automated CAD 
system for crankshafts: 

3.1 Modeling of basic shape (portions defined by structural 
consideration) 

As stated earlier, crankshafts have two types of surfaces; curve-driven surfaces 
(three kinds of analytically defined surfaces) and free-form surfaces (blend 
surfaces between those curve-driven surfaces). If the crankshaft geometry were 
built only by curve-driven surfaces, it would be possible to define each of those 
surfaces parametrically and to transform its shape variationally with ease. But 
actual crankshaft geometry will definitely contain lots of free-form surfaces (draft 
surface and blend surface) and it will never be possible to parametrically or 
variationally handle those geometries by a conventional process. 

In this study, a new concept of “procedure oriented constraint handling” has been 
applied to improve 3D modeling of crankshaft; for better stability of surface 
blending, quicker response to engineering change, and standardization of modeling 
operation. 

There are two features in conventional modeling technique done by skilled 
designers that were referenced to this new concept: 

Modeling rules 

A conventional process of generating curve-driven surfaces and inserting blend 
surfaces between those analytically defined surfaces can be controlled by a 
“modeling process rule” that dispenses with tricky hierarchical structure in the 
modeling operation and hence makes it much simpler by enabling the designer to 
handle both types of surfaces in only one level. 

Simultaneous treatment of curve-driven surface and blend surface 
Extension of the modeling rule mentioned above makes it possible to treat the 
curve-driven surfaces and blend surfaces at the same time. A class concept is 
introduced to define the minimum unit of generating each surface. In this study, 
two classes to generate curve-driven surface and blend surface have been applied 
as the new concept CAD system. 

A method to define these three types of curve-driven surfaces (extruded surface, 
revolved surface, and ruled surface) with this class concept is shown in Figure 3.1. 
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A newer class for another type of curve-driven surface will be produced by 
combining those basic classes with a special I/O facility. It then can be replaced by 
a procedure of connecting these types of classes such that all of those classes be 
utilized within a specific common domain of crankshaft. 




Figure 3.1 Three kinds of generation classes 



Figure 3.2 shows an example of a basic class called JOURNAL that defines the 
surface on the main journal side of crankshaft counterweight. This class requires 
two kinds of data input operation; geometry data in IGES format called JOURNAL 
and the draft angle value. 




IGES format data (JOURNAL Curve) Curved surface that has drawing incline 

added value of drawing incline a die forging of a die forging (JOURNAL Surface) 



Figure 3.2 An example of curved surface generation process rule to obtain the 
drawing incline of a die forging. 



In a manner stated above, every class library can be defined for the total domain of 
crankshaft. Class libraries that are actually used for production will be created by 
arranging this concept with field information from skilled operators which is 
collected by interviewing them upon their own modeling rules they have within 
their know-how. 
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3.2 Class library (repository) of modeling process of various curved 
surfaces 

A method is explained to make a new curved surface generation class, by 
combining the basic curved surface generation class with the I/O facility for curved 
surface generation. Three basic curved surface generation classes, extrude-surf, 
revolved-surf and ruled-surf are shown in Figure 3.1. 

At first, a new curved surface generation class is made by combining basic curved 
surface generation classes. Next, it can be replaced by the procedure of connecting 
this class to the curved surface generation process of the die forging crank-shaft 
modeling domain. An example which uses one of the basic curved surface 
generation classes, the extrude-surf, is shown in Figure 3.2. Extrude-surf forms a 
curved surface of a surface called JOURNAL. This basic generation class uses two 
input values, the geometry shape of IGES format called JOURNAL and the incline 
value of the die forging. 

By using this method it is possible to build the class library. A curved surface 
generation process rule, can be arranged by the modeling process that craftsmen 
can specifically state with the given rule format in addition to the above procedure. 

3.3 Blended surface 

The surface blending process to generate a 3D surface of crankshaft using this new 
concept CAD system is as follows: 

1. A 2D basic contour is drawn in 3D space. 

2. A 3D wire-frame is defined by manipulating this basic contour in 3D space. 

3. Other main geometric elements are defined that are commonly used in 
crankshaft such as draft surface and parting plane. Curve-driven surfaces that 
would overwhelm the whole model of crankshaft are also defined at the same 
time in the forms of extruded surface, revolved surface, and ruled surface. 

4. The created model in this manner is trimmed and blended such that unnecessary 
portions of surfaces be eliminated and every sharp corner be rounded. 

Among the four steps above, process 4 is the most important in actual modelling of 
crankshaft. 

Although there may be another argument that the lead time of 3D modeling 
process could be shortened by replacing the conventional type of surface (Bezier 
etc.) with NURBS (Non-Uniform Rational B-spline), it is not a fundamental 
solution in improving the modeling process itself. In actual modeling operation, it 
would not be sometimes easy to blend even simple-shaped edge. Figure 4.1 is an 
example which shows that blending cannot be completed on a edge where two 
curves (one built with a series of arcs and the other with line and arc) meet 
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together. In this case, smooth fillet cannot be fitted in due to too large radius 
against the length of the curves. 



4 DIE FORGING MODELING PROCESS 

A typical procedure of generating three dimensional curved surface shapes of a die 
forging crank-shaft, using the developed CAD system, is as follows: 

I. Making a two dimensional fundamental contour in the three dimensional space. 

II. Making the three dimensional wire-frame model by developing the above 
contour figure in the three dimensional space. 

III. Modeling typical geometric elements seen especially in die forging products, 
such as incline sides and parting sides. The analytical curved surfaces that 
fundamentally cover the whole model are at the same time defined as the wire- 
frame model. These analytical curved surfaces consist of extrude surfaces, 
revolved surfaces and ruled surfaces. 

IV. Trimming and filleting the modelled geometry, which cuts the unnecessary 
parts, and rounds the sharp edges between the modelled curved surfaces. 

From the above, process IV, has the major importance in this modeling procedure 
of three-dimensional die forging geometries. 

It has been demonstrated that the lead time could be shortened by half when 
shifting from Beizer curved surface to NURBS (Non-Uniform Rational B-spline 
Surface), in the three dimensional curved surface modeling procedure. 

But it is not enough to improve the performance of the surface modeling system. 
It is required to introduce the knowledge of skilled craftsmen into the CAD system. 
The modeling process took into account the craftsmen expertise, using it as an 
important part of the geometric modeling system based on NURBS. This led to an 
efficient, reliable and fast modeling activity, performed by the developed CAD 
system. Several examples show the applicability and availability of the developed 
system. 

In real die shape, it may not be possible to insert a fillet even in a simple edge 
shape. For example, when an edge is formed by a series of an arc, a linear line and 
an arc, as the one shown in Figure 4.1a, a smooth fillet will not fit in, because the 
radius is too big for the length of the linear line. A mathematical inconsistency 
occurs when trying to adjust the fillet’s radius to the length of the linear line. 

In this situation, craftsmen usually remove the linear line from the edge, using 
modeling knowledge, and then directly join one arc with another. This modeling 
knowledge can simplify the die shape and it is practical in use. It is convenient to 
handle the above-mentioned procedure as the modeling rule shown in Figure 4.1b. 
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5 NEW-CONCEPT CAD SYSTEM 

The CAD system introduced in this study with a new concept was developed based 
on the architecture shown in Figure 5.1 which consists of three units; 3D 
CAD/CAM module, intelligent CAD construction tool, and automatic modeling 
module. 

At first, 2D contour is drawn in 3D space using the 3D CAD/CAM module (3D 
CAD that is commercially available) as shown in Figure 5.2a. A surface blending 
operation will then be added with the automatic modeling module that was newly 
developed for this study (Figure 5.2b). Finally, an optional operation is added 
again with the 3D CAD/CAM module for any exceptional case when knowledge 
capturing was not successfully done beforehand. In this case, the miss-treated 
portion of the model is repaired by conventional 3D CAD operation. 

5.1 System flow 

Adding to the system procedure described in the previous section, its 
system flow will be briefly explained below: 

• Module “Basic Model” first generates basic elements of curve-driven 
surfaces and trims them. 

• Module “Filleted Model” then adds surface blending based on the modeling 
rules. 

• Module “Interactive Model” gives alternative process of interactively adding 
blended surface onto the model. 

• IGES formatted data and other various parameters related with are stored in 
the data base. 
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• Finally “3D CAD/CAM” gives an option to modify the model interactively 
same as skilled operators will do on conventional 3D CAD systems. 
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Figure 5.1 Crank-shaft CAD System 




Figure 5.2a Interactive shape generation 
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Figure 5.2b Automatic modeling module 




5.2 Function of each module 

The developed modules in the CAD system are shown in this section. 
LIBRARY (“Library for defining the surface model”) 
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This function is a very important module that determines all of the basic tree 
structure of the whole model. There are two types of classes that define curve- 
driven surfaces of crankshaft; a group of functions to generate basic surfaces 
(surface definition, surface blending, and surface trimming) and extended 
application for creating other complexly blended surfaces along a series of surface 
patches that are particularly used for crankshaft. 

When a library gets ready, the whole shape of crankshaft can be described in a 
special program format and any other modeling knowledge can be easily added to 
the library. 

RULE (''Rules to restore IGES/basic surface”) 

This function intelligently handles two types of CAD data; geometrical data of 3D 
CAD in IGES and attribute data in text format. 

By activating the classes of curve-driven surfaces, data table of such rules that are 
already prepared will give a rough geometry of the model (without the blend) and 
then add the blend. 

At first, each geometric element and its corresponding attribute are imported from 
IGES data and text data such that those combination can be explicitly identified by 
the layer number. Basic elements of curve-driven surfaces will then be defined by 
attribute data described by rules and data list that can be altered by skilled 
operators. 

“Algorithm for complex trimming” 

A provisionally blended surface with a small radius is defined where there is an 
intersection between the surfaces as shown in Figure 5. 2d. Unnecessary portions of 
those surfaces will then be trimmed off to generate the Basic Model (rough model 
without blend). 

“Function to execute/control fillet sequence” 

When there occur some difficulties in trying surface blending in generating a 
Filleted Model, this function with higher priority to “Rules for restore IGES/basic 
surface” is executed to automatically rearrange the order of modeling steps within 
the rules or to change the classes instead of having operators vary the initial values. 

“Compatibility for rule-based/manual filleting” 

The modeling rules and the order of modeling steps can also be interactively 
controlled by this function (with higher priority to “Rules for restore IGES/basic 
surface”) when operators indicate the change of the blending process and the 
addition of check items. 
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(a) Fillets of minute radius 



(b) Fillets of normal radius 



Figure 5.2d Algorithm for complex trimming 



GUI(Graphical User Interface 
“Function to select fillet type” 

This function is a module used for blending and trimming simultaneously for two 
curve-driven surfaces as shown in Figure 5.2b. It is mainly used when making a 
change in the blend type interactively; from fixed radius fillet to variable radius 
fillet for instance. 

“Function to add macro for filleting (Source Code Generator)” 

This function is a module used for generating macro programs by utilizing 
conventional surface classes interactively for difficult blending operation with the 
rule base or with an existing blending procedure. 



CAD/CAM Modules(consists of the following two functions 
“Function to add geometry/attributes” 

This function is a module used for capturing geometric data and attribute data from 
drawings. It actually works in this study on a 3D CAD system to output attributes 
as an intermediate file and geometric shape data as an IGES file. 

“Data base” 

All information created as stated above is stored/restored in external devices 
(magnetic disks) in ASCII format with this function module. 
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6 SUMMARY 



A new-concept CAD system, developed in this study, would automate the 
conventional process of crankshaft forgings, designed those proved capable of 
being practically used for actual CAD/CAM operation with good enough 
productivity. 

Several types of curve-driven surfaces were used to test the possibility of 
automating the 3D modeling process of crankshaft. 

However, it is still required to capture more knowledge when this system is to be 
applied to the actual field operation by veteran operators. 
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Abstract 

In the Japanese Steel Industries, computers were applied to the manufacturing 
planning in the middle of 1970’s and afterwards the total information systems of 
the steel plant in the field of manufacturing management have been developed. In 
consequence, productivity in the field of manufacturing has been improved. 
Furthermore, recently, the white-collar productivity in the field of management has 
been recognized as a major problem to be solved to cope with the international 
competition. In this paper, we propose the concept, its applications and 




infrastructure of information systems to improve their productivity. These days, as 
a result of decision making down-sizing, the problem-solving approach of white 
collar staff will be changed from the legacy “deterministic approach” to the 
“biological approach”, in which we solve problems by way of iterative hypotheses 
and verifications. We propose one-stop-shopping and seamless information 
systems which are distributed on the main information LAN in the works and 
suitable for white collar activities. In order to realize this concept, we constructed 
the FDDI local area network and developed some applications which make use of 
multi-media data such as bitmap images and photos. 

Keywords 

local area network, FDDI, multi-media, one-stop-shopping and seamless, 
manufacturing management, white collar productivity, information system, 

biological approach 



1 INTRODUCTION 

Nippon Steel’s Hirohata Works first introduced computers for production 
planning and scheduling in around 1965 and has since developed the integrated 
information systems by introducing computers to all levels of production control 
within the Works. These main systems, mainly, operation control system, 
contributed greatly to the improvement of productivity of the Works, producing 
various effects. 

In more recent years, the improvement of productivity of the clerical and 
administrative organizations has become increasingly important to improve 
international competitiveness. As the productivity of white-collar employees is 
not labor-intensive, the improvement of their productivity lies in how their jobs 
can be improved or renovated in an effective and creative manner. The role of the 
information system is to back up such improvement or renovation. In this sense, 
the development of information system which contributes to the improvement of 
productivity of white-collar employees at steelworks has become important. The 
present paper describes how the information system (information system in a 
broad sense, including the planning support system at the steelworks) should be 
built under a consistent philosophy, citing concrete examples. 

2 PROBLEMS IN THE MANAGEMENT OF STEELWORKS AND 
MEASURES TAKEN FOR SOLUTION 

2.1 Background of the development of information system and 
features of the system 

The features of activities in the steel industry are as follows: 

• Order-based production system 
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• Utilization of trading firm’s functions for distribution 

• Total integrated management system, centering around steelworks 

• Long and diversified processes from the raw materials stage to end products 

• All manufacturing processes and the transportation processes connecting 
these manufacturing processes with each other are batch processes. The 
production lot becomes progressively smaller in the direction of downstream 
processes and close through-process control is required. 

• Non-stop 24-hour operation 

Since the 1960s, the steel industry has developed the information systems 
which are fully geared to the features of the activities described above. 

In the 1960s, the development of batch control system and then on-line 
integrated steelworks management system which run nonstop for 24 hours 
throughout the year was started in step with the development of general-purpose 
computer. 

In the 1970s, the enlargement of general-purpose computer and the stabilization 
of computer technology urged the start of development of integrated production 
control system, building of process computer systems for controlling the 
operations of plants, such as rolling mill plant, in the steelworks and their 
interconnections to meet the needs of those days for cost reduction through 
manpower saving and energy conservation. 

In the 1980s, effort was directed, for example, toward the development of 
systems, such as order entry system linking the steel company with trading firms, 
aiming at the improvement of non-price competitiveness for the improvement of 
operation efficiency, strengthening of sales competitiveness or price 
differentiation, and the building of systems, such as total material flow control 
system, aiming at further personnel retrenchment. 

In the 1990s, the development of strategic information system, aiming at the 
systematization of major activities, the systematization of engineering business, 
and the rebuilding of systems for system cost reduction were started. 

In addition, the systems utilizing the advantages of the man-machine interface 
realized by shifting the characters terminals to graphics terminals and the planning 
and diagnosis systems utilizing the AI method were developed in response to the 
widespread acceptance of workstation and personal computer. 

The company’s major activities are covered by these information systems, 
producing remarkable results through stabilized operations (Ito,1992 and 
Furukawa,1991). 

In recent years, the situation that confronts the steel industry has been changing, 
making it necessary to respond to new problems. The problems in the 
management of the steel industry are described in the next section. 
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2.2 Problems and measures taken for their solution 



Users’ steel product purchasing strategy is changing. Namely, recent trend is 
toward the simplification of manufacturing specifications for steel products and the 
diversification of steel product supply sources, including purchase from Asian 
countries. To meet these trends, it is necessary for the Japanese steel industry to 
further improve its international competitiveness on a dollar basis (Osada ,1993). 

The Japanese steel industry has been taking the following measures to meet 
these problems. 

(1) Improvement of the international competitiveness of white-collar employees 
To preserve international competitiveness, it is necessary to change the type of 
organization of staff divisions to improve their productivity in addition to the 
improvement of productivity of the manufacturing divisions which is now 
reaching the limit. In other words, the downsizing of decision-making through the 
reduction in the number of managerial classes and in the number of white-collar 
employees to an elite corps is necessary. The speed of management to respond to 
changes in business climate and the accuracy of decision can be improved through 
such downsizing. 

Examples of the reduction in the number of managerial classes in the world are 
shown in Table 1 . 

Table 1. Transition of the number of managerial classes in the world 



Company 


Number of 
Old 

Hierarchy 


Number of New 
Hierarchy 


Hierarchy 


POSCO 


6-^10 


3 


Executive Committee 
Department Manager 
Team Leader 


National Steel 


8 


4 


President 
Vice President 
General Manager 
Manager 


Nippon Steel 
Corporation 


7 


4 


Executive Committee Director 
General Manager 
Group Leader 



(2) Mini-mill type business management 

Hitherto, the steelworks has been a division specializing in manufacture. In the 
future, however, the steelworks will be required to run its business in a compact, 
slimmed down and integrated manner as a small company, covering materials 
purchase and sales in addition to production. 
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To realize such a flat organization and mini-mill type management, the 
conventional decision-making method must be improved. Namely, the 
information transfer method, judgment information level and decision-making 
method must be improved. The improvements to be made are summarized in 
Table 2. 

Table 2. The functions for improvements to be made 



Item 


Previous Method 


Functions for Improvements 


Communica- 
tions Media 


Conference + Telephone 


Effective Communications 


Information 
for Decision 
Making 


Data Stored in each 
Application System + 
Document of the Data 


Standardized Business Structure 
Storing Data Cooperatively 
Flexible Retrieval 


Decision 

Making 


Explanation of Prepared 
Draft + 

Process of Obtaining 
Sanction of Executives 


Effective Collaboration 

Flexible and Prompt Judgement Based on 

Evaluation of Case Study 



3 INFORMATION SYSTEM BASED ON NEW CONCEPT 

3.1 Basic concept 

In the conventional hierarchical organization, decision-making is limited to top 
management only. In recent years, the down-sizing of decision-making has 
become widespread as a result of the flattening of organizational hierarchy. In this 
type of decision making, each white-collar employee must make a decision 
rapidly. For this purpose, each employee must perform multiple jobs at the same 
time and the information system must be designed to back up each employee. 

On the other hand, approach to the solution of problems in the job area of 
white-collar employees will be changed from the so-called “deterministic 
approach”, in which the methodology for solving problems is determined, to the 
“biological approach” in which problem setting and the methodology for solution 
are not determined but an appropriate solution is obtained by repeating 
hypothesizing and verification (Shimizu, 1990). 

Fig.l shows an image of business evolution by the hypothesis and verification 
type biological approach. The hypothesis and verification type approach for 
problem solving is described below (Ito and Saka,1995). 
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Hypothesis 2 



STAGE 2 

t 




Evolution & Inorivement of 
Business 



•0[ Hypothesis 1 | |a | : STAGE 1 




Fig. 1 An image of business evolution by the hypothesis and verification type 

biological approach 

• Problem setting: The problem or subject to be solved is identified or found 
out. 

• Information gathering: Information is collected. 

• Analysis and making of hypothesis: A hypothesis is made based on the 
results of information analysis. 

• Creation of theory: A theory is created. The problem in question is 

explained or a solution is worked out by creating the hypothesis in one’s own 
way. 

• Verification: The created theory or solution is verified through simulation, 
experiment or practice. 

• Evolution: The hypothesis or theory is improved many times until the best 
answer is obtained. 

3.2 Concepts underlying the development of information system for 
supporting the hypothesis and verification type approach 

The important concepts underlying the development of information system for 
supporting the hypothesis and verification type approach described in the 
preceding section are outlined below. 

(1) Consolidation of tasks through integration of information 

The tasks which have hitherto been carried out through multiple functional 
organizations are simplified by using the shared data base and information 
processing function. 
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For this purpose, it is necessary to create a class library for steelmaking 
business by analyzing the data. Based on this class library, the production results 
and know-how are accumulated. Moreover, the accumulated information base 
(results & know-how data base) is effectively created. 

(2) Accumulation of raw data 

In the past, for example, the individual data was individually processed and a 
stereotyped decision was made. It has become necessary to change this 
environment so that a decision is made based on the results of a variety of analysis. 

For such analysis and decision, the raw data collected at a point close the data 
generation source is required instead of processed data. 

Table 3 shows a comparison between the data base storing preprocessed data 
and the source data base in which raw data is accumulated (ledger system). 



Table 3. A comparison between the data base storing preprocessed data and the 
source data base 





Data Base Storing 
Preprocessed Data 


Source Data Base 


Feature of Stored 
Data 


* Preprocessed Data 
*Poor in Contents 


*Raw Data 
*Rich in Contents 


Feature 
of Computer 
Structure 


*High Price Data Base 
Engine for Public Use 


*Low Price Data Base Engine for 
Private Use {Man-Machine 
Interface 
*DB + NW +PC 


Utility 


* Regular and One-sided 
Analysis 


* Many-sided Analysis 



(3) Improvement of information gathering capacity of individual employees and 
establishment of job system in which such capacity is fully utilized (Do it yourself) 

In the past, routine tasks were carried out by using the common terminals. 
When the improvement of a system was required, a request was made to the 
division specializing in system development to develop a desired system or modify 
the existing system. As the business improvement cycle has been shortened in 
recent years, however, the following have become necessary: 

• Improvement or renovation of one’s own job by oneself 

• Daily operation by one’s own division itself 

For this purpose, the terminal environment customized for each employee becomes 
necessary so that each employee can freely handle the required information. In 
addition, an organization which offers training, consulting and support for 
troubleshooting at any time required is necessary to allow the full use of such 
terminals. 

(4) Job linkage by utilizing the information network 

The information accumulated on the network in a decentralized manner must be 
fetched smoothly by utilizing the individual terminals which are linked with each 
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other on the network. In other words, the one-stop-shopping-seamless & 
communication (OSSSC) function is required. 

In short, such a system is required in which each person can perform his job 
using the terminal allocated to him personally (one-stop-shopping) instead of using 
the conventional common terminal and the new findings or information obtained 
from each job can be readily communicated seamlessly in an integrated manner 
without data conversion between the information systems which supporting each 
job. 

OSSSC is a digitally integrated network linkage. Namely, the gathering, 
processing, and analysis and evaluation of information as well as consultation and 
settlement and instruction exchange among the persons concerned are backed up in 
an integrated manner. 

So far, the general concept of the following information system which is based 
on a new biological concept and contributes to the improvement of productivity of 
white-collar employees has been described. 

• Quick response by a flexible system supporting creativity and downsizing of 
decision-making 

• Evolution and improvement of jobs in a spiral manner through shortening of 
business improvement cycle and rotation of PDCA circle 

• Digital integration of information to enable the use of required information 
on demand 

Table 4. The key words required for realizing the new information system 





Old Key Words 


New Key Words 


Business 

Structure 


*Plan Oriented 
* Hierarchical Orders 


* Down-sizing of Decision Making 
*Flat Organization 


Information 

Structure 


* Master File and 

Preprocessed Data File for one 
Purpose 

*Data Processing in eac 

Application System 


* Sharing of Information 

* Many-sided View 

* Facility of Acquiring and 

* Processing Information 
*Do it your self 


Implementation 

Structure 


* Basing on Mainframe 

Computer 

* Special-purpose Terminal 


* Equipment of Information System 
Infrastructure 

:Network 

Distributed Data Base 
:One Computer per Person 

* Information Literacy Education 



The key words required for realizing the new information system are 
summarized in Table 4. 
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4 EXAMPLES OF THE MEASURES TAKEN AT STEELWORKS 



Examples of the hypothesis and evaluation type information system developed 
on the basis of the biological approach at steelworks are described below. 

The rebuilding of infrastructure on which the information system is based is first 
described, followed by the information technology support center established for 
the improvement of information literacy to enable all employees to fully utilize the 
infrastructure. 

Now, the respective concrete examples are described. First, the prompt 
production result reporting system developed for early detection of the problem as 
the starting point of the hypothesis and verification type information system is 
described. Then, the decentralized type total technology control system and N- 
TCS (New Total Communication System) which are the means of supporting the 
collection of information necessary for hypothesis and verification are described. 
Finally, the hypothesis and verification type planning system for multiple lines is 
introduced. 



4.1 Rebuilding of information system infrastructure 

( 1 ) Needs of rebuilding 

Needs of rebuilding the managerial information system infrastructure are shown 
below. 

• white collar staff need to use both operational systems and managerial 
systems through their personal computer. 

• they need to handling various kind of data such as production result data, 
plant scheduling planning data and managerial data at the same time. 

• they need to utilize their favorite package software such as a statistical 
analyzing software. 

(2) The architecture of the new network system 

At that time, the Sigma network(Hitachi product) had been equipped in the 
Hirohata steelworks. The overall maximum transfer speed from host computer to 
the computer terminals is limited to 19.2kbps because of the limitation of the 
performance of the installed CCP(communication control processor) . And the 
available protocol on the network was limited to HNA which is the proprietary 
Hitachi protocol. In this network infrastructure, the information activities were 
limited because of the lack of the openness. Or we could not use multi-media 
information and PC. Therefore, we decided to rebuild the information system 
infrastructure. 

The /^network had been utilized for both the operational field and the 
managerial information field. And the managerial information network 
infrastructure was separated from the operational information network in order to 
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upgrade the information infrastructure for the managerial information systems. We 
utilized the existing optical-fiber cable and built the managerial information LAN 
based on the international standard FDDI and TCP/IP protocol could be made to 
be used in order to make use of personal computers instead of the proprietary 
expensive terminals. As a results, the high-speed( 100Mbps) LAN was built and the 
distributed and open network environment where we could use global standard 
hardware and software was made to be available. 

The nodes and the servers were distributed at every sections in steel works. The 
ethemet network systems were also built for the white collar staffs. 

The architecture of the new network systems is shown in Fig2. 




new network: managerial level 



Fig.2 The architecture of networks 
(3) The result of rebuilding 

The information system infrastructure was rebuilt by developing the 
information system network environment (main LAN for information system) 
within the steelworks to change the conventional system built on a large frame. 
On this network, one each personal computer was distributed to each person in 
managerial position. “One computer per person” was promoted by distributing the 
computer to management first so that the persons in managerial position realize the 
advantages of computer by experience. They can also use on-line systems and 
Time Sharing systems through their personal computers with the aid of 
XNF(Hitachi TCP/IP support software for main-frame computer). 
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4.2 Establishment of Information Technology Support Center 

To accelerate the widespread use of personal computers installed at all divisions, 
the Information Technology Support Center was established in response to the 
installation of main LAN for information system. The purpose of this Center is to 
provide the help function to the employees who are at a loss in the use of their 
personal computer. Namely, the Center offers the following services. 

• Education of personal computer users in the steelworks in the method of use 
of basic PC software, word processor software, spreadsheet software, etc. 

• Services and consulting regarding the daily use of personal computer through 
telephone, FAX and electric mail (Inquiry/Guidance) 

• Technical support to divisional system managers (answer to technical 
problems in network interconnection) 

The Information Technology Support Center has made a great contribution to 
the improvement of information technology literacy of the personal computer 
users and divisional system managers in the steelworks. 

4.3 Prompt production result reporting system (Example 1 of 
information system building) 

(1) Purpose and background of development 

In the past, the “prompt production result report” was used to grasp the daily 
production activities at steelworks. Namely, the information written on paper was 
transmitted to related plants and divisions. Under this system, many hands and log 
time were required for transfer, re-entry, confirmation, communication, etc. of 
information, resulting in delay in the detection of problems. 

To improve this situation, an environment was created in which the general 
superintendent and other top management of the steelworks can check daily 
production information first thing in the morning by utilizing the basic LAN for 
information system, thus establishing the foundation for promoting the shared use 
and re-use of information by a small number of managerial persons in the flat 
organization and for the early detection of problems so that the most effective 
action can be taken rapidly at the location where such action is really required. 

(2) Outline of the system 

The out line of the prompt production result reporting system is shown in 
Fig.3. 
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Fig. 3 Outline of the Prompt production result reporting system 



(3) Features of the system 

The features of the system is shown in Fig.4. 




Fig.4 Available information by Prompt production result reporting system 



4.4 Decentralized type total production technology control system 
(Example 2 of information system building) 

(1) Purpose and background of development 
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There are the following needs for the decentralized type production technology 
control system within the steelworks. (Goto , 1989 )(Yamazaki,1989): 

Best method of use of total production technology control (SGK) data and process 
computer data to obtain the effects which offset the costs incurred in data 
collection. Obtaining new findings through multivariable analysis of correlations. 
Transfer of technology and know-how, aiming at the reduction in the number of 
analysts to an elite corps and support to operation technology which is advancing 
day by day. 

Shortening of the cycle required from the investigation of causes of quality 
troubles to the determination of appropriate counter-measures. 

Further improvement of product quality. 

(2) Outline of the system 

The operation data is gathered into the database of the main frame for the 
collection and analysis of the information necessary for hypothesis and 
verification. The data is held for one to three years. Of these data, the data for the 
latest three months is transferred to the server of the division at regular intervals. 
Each staff extracts the data required for him and uses it for analysis. The 
configuration of the decentralized type total production technology control system 
is shown in Fig.5 




Fig.5 The configuration of the decentralized type total production technology 
control system 



(3) Features of the system 

The distributed RDB is used as the DB of analytical server. The personal 
computer for each employee is basically equipped with simple DB and spreadsheet 
software. If necessary, an integrated analytical software which enables 
mutlivariable analysis is equipped. 
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4.5 N-TCS (New Total Communication System) (Example 3 of 
information system building) 



(1) Purpose and background of development 

The following are made possible by realizing the shared use of document 
information: 

• Improvement of productivity of white-collar employees 

• Transfer of document information 

The background of development is as follows: 

1984 ~ : Installation of maintenance technology information control system 
LAN for Maintenance Div., 15 terminals for exclusive use 
1992 ~ : Stepped up to TCS 

LAN covering the whole steelworks, 45 terminals for exclusive use 
1997 ~ Stepped up to N-TCS 

Shift to personal computer for OA 
Utilization of multi-media document server system 



(2) Outline of the system 

|PC Clien 
PC Client 



PC Client 



Document 
Management.^^ 
Server,P 1"^*^ 



Document 
I Management 
Server2 



.O 

Data 



Document 




Document 


Management 

Servers 


( Main Information LAN L 


Management 

Servers 



^ |PC Client 



|PC Client Ip PC Client 



■^PC Client 

Document J I ^ 

Management Mpc Client 1 

Serverd I ^ 



*-Data 



|PC Client 



LS pc Clien t 



PC Client 

400 Sets 



Fig.6 Outline of the N-TCS 



(3) Features of the system 

Various types of information can be handled by the same terminal. 

Total number of documents catalogued: About 230,000, including about 60,000 
technical documents and about 30,000 maintenance know-how documents 
Used for preparing work instructions at the plants (usable for 24 hours) 

Examples of information that can be used by N-TCS are shown in Fig. 7. 

Fig. 8 shows the co-ordinated type work flow in which the information shown in 
Fig. 7 is used. 
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Fig.8 The co-ordinated type work flow 



4.6 Planning system for multiple lines (Example 4 of information 
system building) 



At Hirohata Works, the AI method was hitherto used for planning systems. In 
this method, the best solution was obtained out of multiple solutions by conducting 
simulation (Okinaka and Yamazaki 1989). Based on this philosophy, it is planned 
to create a hypothesis and verification type integrated system environment. For 
this planning, it is necessary to make a plan by multiple staff members. This 
planning system is an example of coordinated activity type groupware which is 
required for the future type organization (Nishigaki 1992). 
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The method of preparing the production plan is described below. (See Fig. 9.) 



Preparation 




Fig. 9 The method of preparing the production plan 



(1) A draft plan is prepared after collecting the required information. It is 
necessary to rotate the PDCA circle rapidly by evaluating the draft plan according 
to the actual data and correcting or modifying the plan based on the results of 
evaluation. 

(2) For the determined results, it is important to release the information just in 
time so that all persons concerned can share the information. 

Each main function in the preparation of production plan corresponds to each 
element of the PDCA circle. The formulation of production plan is one of 
hypothesis and verification type tasks. 

The needs for each function and the information technology required for 
realizing such needs are summarized in Table 5 and 6, respectively. 

And in order to realize this planning system, the managerial information LAN 
is fully utilized. 

5 CONCLUSION 

In view of user need diversification, it has hitherto been difficult to build an integrated 
information system in a well-controlled manner on the whole. Nippon Steel’s Hirohata 
Works has succeeded in integrating the systems developed individually into a support system 
for improving the productivity of white-collar employees under a concept of “biological 
hypothesis and verification system”. By utilizing systems proposed here, the productivity of 
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white-collar employees has been increased so much. Compared to that in 10 years ago, the 
number of white-collar employees in 1998 is less than 40% in works. We should be very 
happy if our proposal is of reference to the persons concerned. 



Table 5. The needs for each function required for realizing plaiming system for 

multiple lines 





Needs for each Function 


Preparation 


* Acquiring Proper Sound Data for Planning Production Plan 
♦Insurance of Flexibility in Viewing Information for Deciding 
Production Plan Policy 


Plan 


♦Making Clear Procedure of Production Plan and Telling Business 
Knowledge from Generation to Generation 


Do 


♦Calculating Accurate Evaluation Parameter of Production Plan in a 
Short Time 


Check 


♦Verification of Plan According to Analytical View Point 


♦Understanding Problem in Common between Schedulars 
♦Forecasting Range and Level Affected by Revising Plan 


Action 


♦At First Schedulars Revising Plan Independently and then 
Coordinating on the Whole 


Sharing Information with 
Persons Concerned 


♦Sharing Released Schedule Timely 
♦Showing Details if Necessary 



Table 6. The information technology required for realizing plaiming system 

for multiple lines 





Information Technology 


Preparation 


♦Constructing Data Base for Planning Production Plan 
♦Constructing Decision Support System by End-User Computing 


Plan 


♦In Case of Planing Production Plan Manually->Visualizing 

Production Plan Logic 

♦In Case of Planing Automatically 

-> Automatic Planing System Using Artificial Intelligence and 
Genetic Algorithm 


Do 


♦Development of Real Time Simulation Algorithm 


Check 


♦Constructing Environment for Analyzing Simulation Result by 
End-User Computing 




♦Showing Schedule Visually 
♦Development of Sensitivity Analysis Model 


Action 


♦Development of Computer Supported Cooperative Work 


Sharing Information with 
Persons Concerned 


♦Equipment of Intranet Environnment 
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Abstract 

In order to increase their competitiveness, companies optimize their manufacturing 
processes by adapting structures to the requirements of technology and market. On 
the other hand, they try to fulfil specific requirements by extreme customer 
orientation and manufacturing on demand. This leads to new organizational 
structures and manufacturing systems. Appropriate organization forms, such as the 
fractal company, are distinguished by high flexibility, rapid adaptability and 
exploitation of human potentials. However, these manufacturing companies also 
require appropriate PPC-systems (Production Planning and Control system) or, 
rather, new methods of PPC. In addition to high planning reliability, these systems 
have to ensure high flexibility, distributed processes of planning and decision- 
making, general orientation towards common goals, and an information flow that 
conforms to the requirements. The most important elements of such a PPC-system 
are long-range analysis of the production structure, medium- and long-range 
planning for the entire production area, short- and medium-range coordination 
among production fractals and short-range shop-control inside the fractals. At the 
Fraunhofer Institute for Manufacturing Engineering and Automation, simulation- 
based systems are being developed to support the planning and control of such 
organization forms within production. The user is put into the position of planning 
job orders reliably and optimizing production, concerning cost and schedule 
reliability, by making use of the advantages of decentralized structures. 



Keywords 

Fractal Company, Decentralized Production Planning and Control. 




1 INTRODUCTION 



In order to remain competitive, enterprises are forced to optimize their production 
processes by constantly adapting to the highly dynamic environment. In today’s 
economy, companies are facing increasing competition and high cost pressure in 
an ongoing globalization of the market. The product life time, the quantities, and 
batch sizes have decreased. At the same time the service life of products and the 
number of variants has risen continually. Complex corporate joint ventures and a 
radical change in customers’ behavior represent further evidence of an increasing 
complexity. A shift is recognized from a sales-oriented market to a customer- 
oriented market. More and more, customers expect services and products to be 
tailored to their specific needs. High price/quality and high service/delivery 
performance is expected from the supplier (Matthyssens, 1994). In Figure 1 the 
essential characteristics of the market conditions are shown. 
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Manufacturing on Demand 



Figure 1: Customer-oriented manufacturing under turbulent market conditions. 



Corresponding to the turbulent market conditions, flexibility has become an 
important factor in the development of new production concepts such as, for 
example, the Fractal Company (Warnecke, 1993). The concept is based on small 
but powerful and dynamic manufacturing units, the fractals, which operate in a 
very customer- oriented way within a production network. Manufacturing on 
customer demand requires flexible production facilities which can quickly adjust 
to the market changes. 

The management of the production of these fractal manufacturing networks is 
the key to a companies’ competitiveness. Besides an adapted product structure 
there are two important aspects to be met when realizing this type of production: 
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1. Production structure based on the system technology in order to obtain a 
comprehensive and autonomous performance optimization. 

2. Integrated, decentralized production planning and control (Zaepfel, 1989) in a 
flexible and dynamic manufacturing network. 

2 FRACTAL PRODUCTION 



Manufacturing enterprises are traditionally structured on the basis of labor 
division. Their structure still follows the philosophy of optimization through 
detailed planning and application of the classical methods of factory focusing on 
the goal of maximum utilization of the existing resources as regards technical 
capability and time. For the first time, the philosophies of the fractal (Warnecke, 
1993) or agile enterprise (Noaker, 1994; Kidd, 1994) are breaking with this 
tradition as they favor self-organization and self-optimization: The employees 
themselves are responsible for the layout of the performance centers. 

Figure 2 illustrates the principles of the fractal factory as defined by Warnecke 
(Warnecke, 1993). Each business unit acts as an autonomous factory which is 
integrated within a communication network. In the view of organization the 
business units are similar. They optimize themselves and are integrated in a 
hierarchical system of objectives and managed in an organization network. 
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Figure 2: Principles of the Fractal Factory (Warnecke, 1993). 

A field of production such as the mechanical production, is a complete system 
consisting of several subsystems, for example the manufacturing cells. The 
subsystems again can be divided into further subsystems. They are linked with 
each other according to certain laws like the workpiece or tool cycle. The methods 
of Total Quality Management (TQM) are applicable to the customer- supplier 
relationship between the individual elements. 
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Today, some enterprises are already entrusting the suppliers of the machines and 
facilities also with their operation including the provision of technology, tools and 
equipment as well as the personnel. Thus, the machine supplier himself becomes 
an operator. In this value adding process, he takes the responsibility for the 
utilization and optimization as a provider of services with the machines produced 
by himself. 

3 FRACTAL PRODUCTION PLANNING AND CONTROL 

Market demands for short delivery times make planning and control of multi- 
stage, customer order- oriented production difficult and complex. So far, neither 
rough scheduling PPC-systems nor disjoint local control stations, based on 
conventional forms of production organization, have been able to manage the 
enormous coordination effort for planning multi-stage linked production. Thus, the 
objective was to develop an integrated system from globally coordinated planning 
and short-term production control with distributed cooperative local control 
stations, on the basis of the Fractal Company concept. The expected benefits of 
such a system are reduced inventories and lead times, and an increase of the 
delivery reliability. In the past few years, the Fraunhofer Institute for 
Manufacturing Engineering and Automation (IPA), Stuttgart has developed a 
system architecture which meets these demands. A prototype is currently being 
used successfully in the industry. 



4 SYSTEM ARCHITECTURE 
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The system architecture for the production planning and control of fractals consists 
of three levels (Figure 3). 

The long-term evaluation of the production structure takes place on the first and 
upmost level where the intensity of relations among fractals is being analyzed. The 
degree of intensity is measurable by the number and the nature of planning 
conflicts. The second level contains an outline model of the entire production. The 
function of this level is to visualize a holistic view of the production, in order to 
determine the overall guidelines for the decentralized units. The function of the 
third level with its detailed, autonomous models of fractals is to carry out short- 
term planning and control. The guidelines are transformed into feasible plant 
programs, changes are issued in case of sudden breakdowns, and conflicts among 
fractals are resolved. 

5 MODELING 



The generation of models happens in two steps. The first step is to develop a 
detailed model of each individual production unit, called a fractal. Subsequently, 
the outline model of the entire production area derives from these models. 




Figure 4: Hierarchy of modeling. 
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The fractal models are used to represent the production processes within the 
individual fractals. The fractal models consist of essential elements for the 
planning and control of production, such as production, transportation and 
inventory systems, as well as strategies to control the material flow within these 
systems. They also contain additional functions, such as statistics and various 
means to evaluate simulation runs. A predefined, configurable fractal model 
facilitates the user's task to generate a fractal model. 

After the individual fractals have been modeled, the outline model of the entire 
production area is set up. Here, too, a predefined model of material flow and 
information flow interfaces exists, of strategies to control the material flow and 
additional functions, such as statistics and the means to evaluate simulation runs. 
Translating and aggregating the detailed fractal models in the outline model 
happens automatically by means of soft-computing algorithms (Figure 4). 

A third element in generating models is to build temporary coordination models. 
In the case of self-organized coordination, a model may consist of two fractal 
models. This modeling type is prompted by conflicting planning operations of 
fractals with direct customer-supplier-relations. The components of the 
coordination model correspond with those of the fractal model. 

6 PLANNING PROCEDURE 

In contrast to the modeling procedure, the planning cycle starts with rough 
planning in the production model (Figure 5). 
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Figure 5: Planning Procedure I. 
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The main function of rough planning is to schedule customer orders. In a 
backward scheduling operation based on delivery dates, the latest possible 
planning date is determined. The resulting order sequence is used as a basis for a 
subsequent forward simulation to schedule the fractal orders, while taking into 
account the current stock situation within the fractals. A fractal order is equivalent 
to a 'time window,' defining the time during which a customer order is processed in 
a fractal. 

The fractal order is used as a guideline for detailed planning in the fractal model. 
In general, this provides sufficient freedom for planning and scheduling, so that 
the fractal planner is able to achieve internal optimizations. The rough planning 
process is followed by detailed planning in the individual fractal models. If it is not 
possible to find a planning variant satisfying the overall guidelines (i.e. time 
allowances for fractal orders) during detailed planning, this might affect the 
schedules and planning of subsequent fractals. In this case, the coordination model 
comes into effect, which has two strategies available to resolve the conflict. The 
first one is called Program-controlled coordination: it combines all planning 
variants of conflicting fractals (generating a disposition window that considers 
both fractals) to find out the optimal combination still complying with the overall 
guidelines (Figure 6). 




Figure 6: Program-controlled coordination. 



If there is still no solution to be found without neglecting the overall guidelines, 
then the second strategy for problem-solving becomes effective. It is based on a 
method called Self- organized coordination. The fractals now make use of a model 
containing all elements of the conflicting fractals that are relevant for the period of 
conflict. The target of this joint planning act is to comply with the combined 
disposition window of both fractals. 
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7 BENEFITS AND APPLICATIONS 



The advantages of the described system for the planning and control of production 
fractals are, for the most part, a result of its architecture. 

Much of the modeling, model maintenance and planning tasks is shifted to the 
production area. This increases flexibility and up-to-dateness of the planning 
system when changes in production occur. The know-how existing in the 
production area can be exploited for planning operations. With the distribution of 
planning activities over several production units, a simultaneous run of planning 
processes is achieved that results in an accelerated planning procedure. Since the 
fractal staff themselves determine the planning results, the planning is more 
accepted and more reliably fulfilled. The scope of action is enhanced by 
transferring planning responsibility into the production area and, in effect, 
stimulating a continuous improvement of the production process. 

The automatic generation of a model for the entire production area ensures that a 
global optimum is pursued. Enveloping complex structures into fractals leads to 
more transparency and facilitates the analysis and evaluation of production. 

Clearly defined customer- supplier-relations among the fractals have the effect that 
weak points are discovered on time. The tool to settle conflict situations 
(cooperation model) supports the user in eliminating the deficiencies and also 
promotes cooperation and the common understanding that solutions can only be 
found in a joint effort. 

A practical example illustrates the benefits of the described system: In a large 
European enterprise the networking of decentralized units through information 
technology changed the whole planning system from an accumulation of disjoint 
production units to a customer-oriented planning cosmos. Increased planning 
reliability and the early recognition of conflicts and bottlenecks together with the 
simultaneous problem-solving support of the planning system created the 
necessary foundation of trust for a stronger networking of production. 
Transparency and orientation of all planners towards customer demands had an 
impact on the management ratios of the considered enterprise. 

A more consistent networking of local planning units and the global coordination 
of planning resulted in a 30 % reduction of work in progress. Since production in 
the described enterprise is aligned to customer orders, the reduction of work in 
progress-inventories is directly connected to a reduction of lead times (by 30 %) 
and delivery times. As the work in progress amounts to the value of $ 100 to 150 
million, the reduction of inventory already results in savings of several million 
dollars each year. 

It is important to make sure that the utilization of the plants and the total 
throughput is not affected negatively by the above described measures. The 
consideration of technological restrictions within the global planning coordination 
even achieved and improved composition of batches and reduced the percentage of 
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set-up times. At the same time, the early recognition of conflicts and the common 
target alignment increased the schedule reliability for customer orders. In the past, 
very few customer orders were delivered on time to the finished products storage. 
Today, a delivery reliability of over 90 % has been achieved. This, in return, 
affected the distribution, so safety buffers between the customer due date and the 
delivery to the finished products storage hardly exist any more. Inventories could 
be further decreased, resulting in a very positive effect on the capital tie-up costs 
at the end of the value creation process. 

Due to the improvement of these performance measures, the enterprise became 
more flexible and agile on the market and economically more efficient in 
production. The described optimization of logistics parameter induced IPA to 
advance the architecture that has been described above. At present, the focus of 
work is engaged in a heterogeneous and international production networks. 
Companies are particularly interested in the rapid adaptability of these networks. 

8 CONCLUSION 

This paper describes a strategy for future production based on the idea of fractal 
and agile enterprises. The actual aim is to realize a type of enterprise operating 
very closely with the market and only on customer demand at the shortest delivery 
times possible. To achieve this, the adaptability of the capacities to specific 
demands has to be increased, and the production planning and control has to be 
modified correspondingly. Thus, the objective was to develop an integrated system 
from globally coordinated planning and short-term production control with 
distributed cooperative local control stations, on the basis of the Fractal Company 
concept. The expected benefits of such a system are reduced inventories and lead 
times, and an increase of delivery reliability. In the past few years, the Fraunhofer 
Institute for Manufacturing Engineering and Automation (IPA), Stuttgart has 
developed a system architecture which meets these demands. A prototype is 
currently being used successfully in industry. 
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ABSTRACT 

The aim of this paper is to point value of auction in hierarchical manufacturing 
system architecture. "Auction" is an interrelation of computer systems and cells, 
and, also cells and stations, in which active database assigns certain jobs to the 
cells, and the cells judge their ability to do the assigned jobs. The cells deliver the 
required jobs to the stations also via active database, and the stations judge their 
ability too with calculation of estimated machining time. The cells estimate the 
machining time according to the most adequate usage of the stations, and 
hierarchically they are reported to the scheduling system. The final result comes 
as the selection of minimum machining time by the computer system. It is 
efficient, for cells are given ability to estimate their possibility in achieving jobs, 
and therefore the total system acts pliably. 




It is true that interrelation between the scheduling systems and the cells has been 
achieved in conventional manufacturing systems, but the systems have 
predominated over the actual cells. In those systems, job information has been 
provided by the systems and the cells have remained subordinate. However, 
recent advancement of the cell controllers and station controllers has enabled to 
administer intelligent information processing even within the cells and stations. 
Cell and station controllers may judge possibility to accomplish assigned jobs, 
generate operation plan, and estimate machining time. 

Therefore, this hierarchical manufacturing system architecture, called "auction" 
should play a key role in re-scheduling in order to cope with potential alteration. 

Keywords 

distributed manufacturing system, dynamic scheduling, production scheduling, 
active database, machining features, flexible features, CAD, CAM 

1. INTRODUCTION 

Levels of automation have been achieved to enhance the efficiency in production 
as synthesis of CAD/CAM systems, automated facilities and scheduling systems. 
CAD/CAM have predominated over production process, and alteration has taken 
place in CAD/CAM even if modification has been required in the actual 
production process. Therefore, this system is unprotected against potential failures, 
such as sudden change in production plan or failures of facilities. 

In order to cope with these problems, distributed manufacturing system with the 
help of "auction" is effective[Arai, E., (1995)]. Hierarchical architecture among 
the total system, the cells and the stations add more flexibility when the cells 
behave independent of each other. Some of controlling features, such as operation 
planning, are given to hardwares of machine tools and robots. These controllers 
are connected in computer networks, and specific problems are dealt in a network 
architecture based on active database system. Final results are given as 
modification of production plan through scheduling system. 

2. SYSTEM ARCHITECTURE 

Interrelationship between the scheduling system and the cells is vital element to 
achieve pliable production plans[Okuno, N., (1992)][Ueda, K., (1992)]. A case of 
distributed production system based on active database is shown here to explain 
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actual procedures in assigning jobs to the cells, and also from the cells to the 
stations with the help of auction(Figure 1). 

First, the production requirements are delivered to the cells. The core part of this 
renovating system is the combination of communication controllers and job/cell 
databases in a network system. The job database stores the production 
requirements, and the cell database stores the functionality and the current status of 
machining cells that is kept updated. 

order 
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Figure 2 Different operations for the same removal area. 



for M-T 2 



In a surrounding area, production scheduling system and CAD/CAM systems are 
connected to the core part. (Material handling system is not considered here). 
Actual machining cells are connected also in this surrounding area. Generally 
production of parts requires specification of kinds and numbers. (Due dates are 
not considered at this point.). Details of parts are described in the CAD system 
using machining features with procedure constraints extracted through recognition 
process in the CAM system[Ranky, P. G., (1992)][Kjellberg, T., (1991)]. 
Functionality of machining cells are characterized by feature classes, accuracies 
and maximum dimensions, and they are kept updated through the network. These 
informations are the basis for the auction. 

Therefore, at this point "auction" plays an important role. For one assignment of 
carving, for example, various operation plans may be presented (Figure 2), but 
intelligent machining cells can make their own operation decisions by selecting the 
most suitable. Definite production requirements are transmitted to the job database 
when they become determined. 

Hierarchically, each cell has the active database system and the scheduling system 
to assign the job to the belonging stations. The station database connects to the 
active database instead of the cell database mentioned above. Functionality of 
stations are also characterized by machining feature classes, accuracies and 
maximum dimensions. The production requirements that are delivered from the 
production systems to the selected cells are passed though to the selected stations 
via active database within the cells. 



3. PRODUCTION SCHEDULING 



Production requirements are given to the production system when it is initialized 
and are sent to the active database. Production requirements consist of the product 
representation which is a set of “flexible features” mentioned in the next section, 
required number, and the due date for each product ordered. The active database 
stores them in the job database, and deliver each of them to the selected cells that 
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are feasible for machining each product based on the functionality and status 
referring to the cell database. 

Repeatedly the cell controller passes through the given production requirements to 
the active database within the cell that decompose them into more detailed 
machining processes, and deliver each of them to the selected stations referring to 
the station database. 

Station controllers calculate the machining time for given processes and reply the 
estimated machining time to the active database. Collected estimations are sent to 
the scheduling system where the machining processes are assigned to the stations. 
The cell controller calculates the total processing time to accomplish the 
production requirement according to the scheduling system within the cell, and 
report it to the active database of the production system where necessary replies 
from the cells are collected and sent to the scheduling system of the production 
system. The cell assignment is executed there. 

There is another important element in the system that is “triggers” to run the 
system. The active database can be elaborated when “triggers” occur. 

Production schedule must be pliably altered when "triggers", or modifying 
elements, are found[Takata, M., (1995)]. In active database, triggers are changes 
in production plans, and in cells, stations, or AGVs they are changes in 
functionality, such as failures, recovery or renewal. 

Three types of triggers are considered ; the first is the change in production plan 
that comes outside the database, the second is the alternation in cells, stations, or 
AGVs such as failures and recoveries, the third also comes from cells, stations, or 
AGVs such as evidence discrepancy between the estimated 
machining/transportation time in the scheduling system and the cell/station/AGV. 
When the trigger is caused by the stations within the cell, the cell controller tries 
re-scheduling so that the assigned production requirements can be accomplished in 
the cell[Iriguchi, K., et al., (1992)] [Adams, K. G. and Huang, S. H., (1992)]. 

Figure 3 shows how the actual task takes place when triggers occur. First, the 
active database sees the job database and picks up the unstarted processes. Then, 
stations are selected for each of processes. It must be clear that stations are 
assigned processes according to their abilities which are stored in the station 
database. Each process is delivered to the selected stations each of them develops 
the operation plan to estimate the machining time. The estimated machining time 
by each station is transmitted to the active database. After sometime the gathered 
information is sent to the scheduling system to generate the production schedule 
(station assignment ). Because trigger will occur frequently in the actual factories. 
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and re-scheduling loads will be heavy, simple rule is adopted here in the 
scheduling system. 



Trigger 




Figure 3 Process flow raised by trigger 



The trigger is generated to the active database of the production system from the 
cell when the re-scheduling within the cell results in unsuccessful. The system 
tries again re-scheduling for cell assignment. 

At this point, "auction” of several consecutive phases takes place, and each phase 
corresponds to respective removal area. Active database collects the replies, and at 
each phase probable cells or stations are selected and sent to the scheduling 
system. After reviewing all necessary phases, selected cells or stations are 
determined and interwoven into production schedule. 
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4. FLEXIBLE MACHINING FEATURES 



As described in the Section 2, part geometry is characterized by several feasible 
sets of machining features. In this section, this process is elaborated by showing 
actual procedure that takes place in CAD/CAM systems [Chang, T. C., 
(1991)][Arai, E., et al., (1994)]. 

First, the removal area is computed by making the difference between the blank 
material and the finished part. The removal area that is composed by the planes 
and cylinders is decomposed by the cutting planes that are generated referring to 
the kinds of edges; concave and convex edges. 

From any edge, cutting faces can be generated by sweeping the edge along the 
sweeping directions. The sweeping direction of the edge can be found from the 
direction of the coordinate system of finished part given by the user. The two 
connecting faces on the edges considered to generate the cutting face must be 
plane-plane faces or plane-cylindrical faces. Edges that connecting faces on them 
are cylindrical faces will not be considered to generate any cutting faces here. The 
number of generated cutting faces depends on the edge types and the direction of 
the coordinate system. 

An example of this decomposition process is shown in Figure 4. Decomposed 
removal area can be presented in the And-Or graph such as shown in Figure 5. 
And nodes in the graph show the decomposed elements. Or nodes show both the 
resulting of the decomposition and the copy of decomposed elements used in the 
decomposition process. Leaf nodes in the graph show all decomposed elements 
found from the root nodes. 




Figure 4 An example of decom- Figure 5 And-or tree representing decom- 
position posed elements 

Designers can represent their intention about machining parts by use of several 
types of descriptions such as tolerance and dimensions. Figure 5 show the two 
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dimension descriptions of the same part. In Figure 6 (a), it is shown that the hole 
or slot can be machined without regarding about their machining order because 
their specifications or positions in the part do not relate with together. But in 
Figure 6 (b), the hole should have to be machined after the slot because the 
position of the hole is shown by relating with a face in the slot. 




(a) (b) 

Figure 6 Two dimension description of the same part 




(a) Original and-or graph 

E B A 




(b) Simplified and-or graph 
Figure 7 Two and-or graphs of decomposition 
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Since the dimension descriptions of machining parts represent both the 
specification of parts and the machining orders among machining features in parts, 
the constraints of machining order considered here as the design intention 
constraint. 

The precedence constraints among machining features can be derived by 
geometric interference that is detected in the geometric modeling system and 
attached attributes such as surface roughness. 

With taking the precedence constraints into consideration, the number of feasible 
sets of machining features is reduced, for instance And-Or graph for Figure 7 (a) is 
simplified as Figure 7 (b). Several sets of machining features for one removal area 
are generated from the And-Or graph, and are used to present the part shape in the 
job database. 

5. CASE STUDY 



For more apprehension, in this section a production system with two cells which 
have 5 stations and 2 AG Vs is taken as an example. 

When production requirement as Figure 8 is given to the system which has station 
data shown in Figure 9, production schedule shown in Figure 10 and Figure 11 are 
generated after executing auction by the active database. In these figures, job 
(1,1,1) and (1,1,2) are assigned to cell 2, and job (2,1,1) is assigned to cell 1. 
Figure 12 shows the schedule of AG Vs. 
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Figure 8 An example of job data 
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Station 

No 


Status 


Possible machining features 


Maximum dimensions 


Performance 
(cutting volume / min) 


1 


BUSY 


TYPEl 


30*~50 


0.04 




30min 


TYPE 2 


30*~30 


0.2 






TYPE 3 


10*~10 


0.08 






TYPES 


20—30 


0.6 






TYPE 6 
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1.2 


2 
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TYPE 3 


o 

• 

o 
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0.4 
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30»~30 


0.7 






TYPE 6 
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1.0 
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20.-20— 20 


0.08 


3 
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40*~60 


0.03 




25 min 
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30*^0 


0.18 


- 


^ 


_ _TYPE2^^ - 
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— 0.11 



Figure 9 An example of station data 




Figure 10 Scheduling result of cells 
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(a) Scheduling result of stations in cell 2 for job (1,1,1) 
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(b) Scheduling result of stations in cell 2 for job (1,1,2) 
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station 1 
station 2 
station 3 
station 4 
station 5 

(c) Scheduling result of stations in cell 1 for job (2,1,1) 
Figure 11 Scheduling results of stations 
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(a) Scheduling result of AGVs in cell 2 for job (1,1,1) 
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(b) Scheduling result of AGVs in cell 2 for job (1,1,2) 
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(c) Scheduling result of AGVs in cell 1 for job (2,1,1) 

Figure 12 Scheduling result of AGVs 

6. CONCLUSION 

In this paper, usability of active database in a distributed production system 
architecture has been discussed. Active database with auction among cells or 
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stations is valuable, for systems can pliably modify the production schedules 
against various changes in actual production processes. This process will increase 
ability in production in more flexible ways. 
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Abstract 

With the increasing use of product data technology and product models in 
particular in the production phase of the product life cycle, approval mechanisms, 
often integrated in workflow models, show shortcomings when they are used as an 
electronical successor of the well known signature below a technical drawing. 
When considering the aspect of the creation of a legal document with an approval, 
questions may arise about the guarantee and provability of the approval authorship 
and integrity of the approved partial model data because of the ease of modifying 
data in computers. 

The paper describes how cryptographic methods can be integrated in the 
approval process to provide a way for establishing the authenticity of the approval 
concerning both the authorship and the integrity. 

When leaving the production phase and advancing to the use and, in particular, 
the recycling phase, it appears crucial that the relationship between approved 
product data used for the manufacturing of a part or assembly and the part or 
assembly itself is only unidirectional. In case of liability, a secure, i.e. unforgeable, 
method is needed to map from the part to the product data from which it was 
manufactured and especially to the approvals which accompanied the production 
of the part. Similarly, a recycler might be interested in the original composition of 
an assembly concerning the materials used in it, e.g. lubrication liquids. 

The paper discusses established as well as new methods to tag parts and 
assemblies with the objective to obtain a similar level of authenticity for the part as 
for the product data which described it. The integration of the tagging methods in 
the production phase will be treated as well. 




Keywords 

Product data technology, Cryptography, Digital signature. Message digest, Hash- 
Function, Steganography, STEP 



1 INTRODUCTION 

Product data is the generic term for all those data that describe a product, i. e. all 
assemblies and parts, as complete as possible under the given circumstances. Often 
this term also includes the data necessary for manufacturing the product, for 
instance tool descriptions, and for managing the development workflow like 
approvals, work orders, or activities. Separated from the product data, the so-called 
meta data is managed which is needed for describing the product data structures. 

When the design of a product component, an assembly or part, reaches a certain 
degree of maturity, it is subject to an approval by one or more responsible 
individuals. The classical approach for an approval is to provide a technical 
drawing of the component which is then examined by the approval engineer(s). 
The drawing is either rejected and returned to the designer for revision or accepted 
and thereby approved to be used as a basis for further development or for 
manufacturing. The drawing, equipped with the approver’s signature, is forwarded 
to the product documentation department. It now constitutes a legally binding 
document for product liability purposes. 

Although the integration of computer systems in the product development 
process has proceeded to a state where component geometry is solely created 
utilizing three-dimensional computer aided design systems (3D-CAD systems), the 
approval process yet remains conservative. A two-dimensional technical drawing 
is derived from the 3D model of the component and plotted on paper. The paper 
drawing is examined, approved with signature, and archived, or, in case of a 
rejection, sent to the designer who changes the marked inconsistencies in the 3D 
model and initiates another approval. Instead of drawing libraries or microfiches 
today electronical methods are often used for archiving. The drawing is scanned, 
converted to a graphics file format that is likely to be readable for part or whole of 
the archiving time provided by law, and then archived on a storage media, mostly 
of the optical write once read many (WORM) type. 

As it is desirable to avoid this type of media discontinuity coupled with the 
incompleteness of the archived product data, an approval of the 3D model seems 
to be logical. The hurdle to be taken is the proof of authenticity of the product data 
necessary for the acceptance as a legally binding document. 

One way to take the hurdle is to use digital signatures as a surrogate for manual 
signatures. The first part of this paper explains what digital signatures are and how 
they may be used in the digital approval process. 

After the product components have been manufactured, they are assembled and 
the resulting product is offered. In the following utilization phase the product 
needs maintenance or, in case of a failure, a repair. The product may even have 
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caused an accident which leads to legal proceedings. And after the utilization 
phase, when the product has become worn or is no longer able to fulfill its 
function, it is disposed or parts of it will be recycled. In all mentioned cases 
product data must be retrieved by information that had been attached to the 
product component by some method during the manufacturing phase. Furthermore 
the producer may need to prove that all parts of the product in question are 
genuine or rather that some parts are not. In the second part of the paper the 
structure of the tagging information is detailed and, for each identified layer, 
already established and new transformation methods are discussed, the new ones 
with respect to obtaining the authenticity of the tagging information or the 
component itself. 



2 PRODUCT DATA AUTHENTICATION 

The product data of a particular product, as it is stored in product data management 
(PDM) systems, can be divided into partial models describing certain views on 
assemblies or parts, for instance, a geometry view or a kinematic analysis view, 
and associated process-oriented data, e. g. an approval of a component design or a 
work order to manufacture a part or to further develop dependent components. A 
record for the latter type of data usually contains the information who initiated the 
activity, when it was initiated, who authorized it, what was to do, when was it to be 
accomplished, and who has done it. The semantics of an approval differ slightly 
but contain the same relationships to the parties involved in the approval. The 
record is set up from the partial model that has been approved, the approval date, 
the approval status (for example, approved for stability calculations, approved for 
manufacturing, or approved for resource planning), and the approvers. 

A forger who is able to gain sufficient access to the PDM system may later on 
change the approved partial model or other data of interest without leaving a 
noticeable hint about this illegal change. Sufficient access means that he may be 
able to break any conventional security method like marking the data as read-only, 
separating the involved computer systems from a larger network, or keeping the 
computer systems locked in a suitably secured room. 

Digital signatures 

In the emerging electronic business over the Internet a method known as digital 
signature is used to cope with this kind of problem. A digital signature is created 
by the signer’s application of cryptographic algorithms on the document to be 
signed. An individual may verify the digital signature by applying corresponding 
cryptographic algorithms. A successful verification not only states that the 
document was actually signed by the signer but also that the document was not 
changed afterwards which is just the set of features demanded from the above 
example. 
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The subject of the cryptography is to keep messages secret. As this can only be 
accomplished if breaking of the secrecy is tried and its cost may then be estimated, 
the sibling science of cryptanalysis was founded. Both constitute the science of 
cryptology (Schneier (1996)). 

Cryptography suggests to encrypt the message with an encryption algorithm 
using a secret piece of information, a so-called key, which is only known to a 
limited circle of individuals. The encrypted message, the cipher, can only be 
transformed to the original message if the corresponding decryption algorithm and 
another or the same key that was used for the encryption are known. The 
knowledge of the encryption and decryption algorithms will not give any 
advantage to a potential attacker if the algorithm pair is sufficiently secure, so they 
are usually published. The only secret is the key or the keypair which consist of a 
bit sequence of finite length / (currently /’s between 128 and 1024 Bit are used). 
Because of the key’s finite length all possible bit combinations may be tested in 
the decryption of an interesting cipher, needing 2^'^ tests in the mean to find the 
key. Therefore, this type of cryptanalytic attack is called brute force attack. The 
only measure to fight this attack is to choose longer keys and algorithms which 
may use them. As each test takes a certain amount of time depending on the 
computing power available to the attacker, increasing the key length by one 
doubles the time for a successful attack. If this time exceeds the lifetime of the 
encrypted data, the keys and corresponding algorithms are rated as 
cryptographically secure. 

Public key algorithms 

The concept for digital signatures that is mostly used these days was invented by 
Whitfield Diffie and Martin Heilman in 1976 (Diffie and Heilman (1976)). It is 
based on so-called public key algorithms which use keypairs instead of single keys 
for both encryption and decryption. If a message is encrypted with the first key, it 
can only be decrypted with the second key (and vice versa). The idea was to keep 
one key secret and publish the other key to all interested individuals. Then the 
owner of the secret key may encrypt a message and send the cipher to someone 
owning the public key. 

When the recipient is able to decrypt the cipher with the public key, he knows 
that the message was encrypted by the owner of the secret, private key. This way 
the cipher acts as a signature of the message which may later be verified by 
applying the public key. 

Certificates 

The keypair for a public key algorithm is created by the later owner of the 
private key but a potential recipient of an encrypted message signed by the private 
key owner needs the public key in order to verify the signature. To provide this 
key in a secure way so that no one can change it on the way to the signature 
verifier is a challenging problem which is solved today by the foundation of so- 



278 




called certification authorities. The creator of the key pair meets with a certification 
authority, proves his identity by showing a passport or some other identification, 
and passes his public key. The certification authority returns its own public key for 
later usage. A potential message recipient will do the same, thus owning the public 
key of the certification authority too. 

If the recipient actually receives a signed message but not yet owns the suitable 
public key, he may request the key from the certification authority which in turn 
sends the key encrypted with its private key. As the recipient owns the public key 
of the certification authority, he may decrypt this message, thereby verifying the 
signature of the certification authority. If the recipient trusts in the certification 
authority’s integrity, he assumes the just decrypted public key to be authentic. 
Therefore, he may try to decrypt the received message and, if successful, accept 
the message as being signed by the private key owner. 

Digital fingerprints 

Public key algorithms tend to slow down significantly when the message that is to 
be signed is rather long (i. e. the time complexity of those algorithms with a given 
message length is polynomial with a polynom degree d>l ov even exponential). 
To allow a long message to be signed in an acceptable time, a so-called one-way 
hash-function is applied to the message yielding a fixed-length bit sequence, the 
digital fingerprint or message digest, which identifies the message. The hash- 
function should hold the prerequisites that from a given fingerprint the original 
message should not be computable, from a given fingerprint a second message 
with the same fingerprint should not be constructable, and the hash-function 
should be fairly easy to evaluate. 

Signing process-related product data 

The application of digital signatures on process-related product data like the above 
mentioned approval or work order is straight forward and is explained in the 
following by choosing the approval as an example. 

Each approver should create a keypair, keep the secret key by his own (in 
particular not integrate it in the product data), and deposit the public key in the 
product data record describing his personality, preferably accompanied by a 
certificate of a certification authority. To simplify the task of public key 
management, only one certification authority should be involved in a product 
development and the authority should be trusted by all participants of the 
development process. Furthermore, the certification authority should be expected 
to survive the lifetime of the product data including the archiving time to guarantee 
the provability of the authenticity of all public keys used in the development 
process for the whole time period. 

When an approver has approved a partial model of the product data, he signs the 
approval by collecting and ordering all data necessary to describe the approval 
including the approved partial model, computing the digital fingerprint of it. 
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encrypting the fingerprint with his private key, and attaching the signature to the 
approval representation in the product data. 

An individual who wants to verify the signature needs to collect and order all 
the data the same way the approver did, compute the fingerprint again, fetch the 
approver’s public key from the product data with possibly verifying it with the 
accompanied certificate, decrypt the signature with the public key, and compare 
both fingerprints for equality. If the signature cannot be decrypted, either the 
public key is wrong and thus the certificate is not trustworthy, or the signature was 
not performed by the approver. If the fingerprints aren’t equal, the product data 
has been changed, given the collecting and ordering algorithm were the same for 
both approval signing and signature verification. In the last case, the fingerprints 
are equal, proving the authenticity of the approval. 

Discussion of the signing process 

Some points of interest should be mentioned about the above approval signing 
process. The approver improves the quality of his signature if he includes the 
signing date and time in the fingerprint computation. This way the approval is 
fixed to the one date which cannot be changed afterwards without notice. 

The list of product data that is collected for building the fingerprint also 
determines the quality of the signature because data elements that are not included 
in the fingerprint will not be signed and may therefore be subject to un verifiable 
changes by forgers. The ordering of the data collection must be identical for both 
the signing and the verification process because of the nature of the hash-function 
which performs a linearization of the graph-like product data structure. 

The algorithm for computing the digital fingerprint turns out to be the central 
component of the signing process because it has to traverse the whole data 
collection with all dependent structures in a predefined and repeatable manner. 
Dobbertin (1996) states thatafter the public key encryption/decryption algorithms 
were subject to extensive attacks, the interest will turn to the cryptographic 
security of the hash-functions in the near future. Thus, designing hash-functions 
from scratch is very dangerous from a cryptanalytical point of view. In 
consequence, the utilization of well known and thoroughly analyzed algorithms is 
recommendable. The main disadvantage of those algorithms, from whom MD5 
(Rivest (1992)), SHA (NIST (1993)), and RIPEMD-160 (RIPE Consortium 
(1992)) are the ones most widely used, in the context of product data 
fingerprinting is their presumption of a linear byte stream as input. Product data 
structures usually constitute an unconnected graph, i. e. a set of connected graphs, 
and in order to fingerprint them, they must be transformed into a byte stream. This 
process is called structure linearization. Algorithms for structure linearization 
depend on specific product data representations and show an inherent complexity. 
They are therefore further discussed in Anderl/Momberg (1998a). 

The longevity of product data exceeds those of most other kinds of data. The 
long-term archiving of product data causes in fact problems on several levels. The 
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storage media on which the product data is deposited must be readable for the 
whole archiving time. The typical solution is to choose optical media, verify in 
defined intervals the readability of the data, and renew the media if they show data 
inconsistencies or if the playback and recording devices are no longer supported 
by the manufacturer. On the data representation layer the current practice is to 
store the data in proprietary formats like those of designated CAD systems. To 
overcome the problem of the data’s incompatibility with newer versions of the 
application systems, either the system vendors are committed to guarantee 
backward data compatibility or the data is lifted manually to a newer version of the 
application system if the readability with the current version cannot be secured. A 
better solution is the use of standardized product data representations, of which the 
most prominent is ISO 10303 Product data representation and exchange (ISO 
(1994)), formerly known as Standard for the exchange of product model data 
(STEP). Their apparent disadvantage that the diversity of state-of-art application 
features are not mappable into standardized representations (which is not necessary 
to satisfy the legal terms) is offset by the published documentation of the standard. 
A software for reading the archived data can thus always be written in the future. 
In this context the integration of digital signatures in product data is particularly 
meaningful when using standardized representations. One approach to integrate 
approval and contract signing in STEP is described in detail in Anderl/Momberg 
(1998b). 

The long archiving time of product data makes particular demands on the 
security of the cryptographic algorithms used for signing. A typical parameter for 
the grade of an algorithm’s security is the length of the keys, in the case of digital 
signatures both the length of the private/public keys and the length of the 
fingerprint. As the computing power available for cryptanalysis is not foreseeable 
for the lifetime of the product data, those lengths should be chosen carefully. “Be 
conservative. If your keys are longer than you imagine necessary, then fewer 
technological surprises can harm you.” (Schneier (1996), p. 168) Schneier 
recommends key lengths above 128 Bit for lifetimes longer than a few decades. 
The state of art in cryptographic algorithms uses 1024 Bit for public key 
algorithms and 160 Bit for hash-functions. The decision concerning the key length 
must therefore be made individually. 

Limitations on the key length are imposed by the export restrictions of various 
countries for cryptographic algorithms (at least if used for encryption). An 
internationally acting enterprise that maintains a globally distributed product 
development is therefore obliged to regulate the key management policy in its 
development projects. 



3 PRODUCT COMPONENT AUTHENTICATION 

The tagging of product components with part numbers, serial numbers, and type 
plates is as old as manufacturing itself. The objective is always to establish a 
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connection between the component and the product data describing it, be it a 
technical drawing, a derived product model like replacement part catalogs or 
service manuals, or the originating product data. Before discussing how 
cryptographic method may create a new quality of product component tagging, a 
classification of tagging methods shall be constructed. 

A product component tag, in the following called tag for short, shows three 
layers of abstraction: the tag representation, the tag presentation, and the tag 
attachment. 

Tag representation 

The tag representation is formed by the tagging information itself. Each 
component in the product data owns an identification which describes either the 
whole series of components manufactured from its product data, the part number, 
or the individual instantiation of the components, the serial number. In numbering 
systems, both are typically constructed from a classification part, an identification 
part, and an informational part (Bernhardt/Bernhardt (1990)), and may be 
represented as a character sequence or purely numerical. 

The classification part describes the component’s integration in a classification 
system, from which the most prominent is the decimal classification, introduced by 
the librarian Melvil Dewey in 1876. Classification systems are usually defined in a 
company-wide manner. Its structure is therefore proprietary and shall not be 
discussed further. 

The identification part identifies the component series, in case of a part number, 
or the individual component, in case of a serial number, uniquely. Frequently this 
will be an increasing number assigned by a central administrative department of a 
company. 

The informational part allows humans to derive the component features directly. 
These include geometrical (length, diameter) and material (metal, alloy, plastic) 
information. 

Tag presentation 

The tag presentation determines how the tag information may be perceived. Beside 
human-readable presentations like a character string, a number or a color 
sequence, machine-readable presentations are in use, typically in combination with 
human-readable presentations to create a certain redundancy and to allow 
readability if the reading machinery is currently not available. Presentations that 
can be perceived by machines are ones suitable for optical character recognition 
(OCR) like the OCR-B font, bar codes like the European Article Number (EAN), 
or bit patterns like the DataGlyphs of Xerox Corporation. The presentation may 
also be influenced by the tag attachment method. For instance, when using 
magnetic ink or paint, a presentation like magnetic ink character recognition 
(MICR) may be chosen, or, when a transponder IC carries the tag information, the 
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presentation may be simply omitted because only the tag’s representation needs to 
be embedded in the transponder’s communication protocol. 

Tag attachment methods 

Almost every manufacturing process can be used to attach tagging information. 
Some are casting, etching, engraving, burning-in, embossing, glueing or coating. 
For manufacturing processes for which a form has to be provided, like casting, the 
attachment of serial- number-like information is typically difficult to perform. In 
this case part numbers or a different attachment method are used. Not only 
adhesive labels may be glued but also holograms which imply a particular 
presentation of the information possibly including 3D optical pattern recognition. 
Under coating the application of ink and paint, invisible (radioactive, ultraviolet 
fluorescent) or visible (magnetic, colored), is summarized too. 

Most widespread are the embossing of alphanumerical information with letter 
stamps, the integration of tagging information in the casting form, the mounting of 
adhesive labels, and the riveting of type plates. More conservative but similarly 
widespread are the labelling of the components with pens, the attachment of labels 
with wires or cords, markings on the component packaging, or accompanying a 
paper describing the component. 

A rather new method is the integration of integrated circuits (IC) in or their 
attachment on the components. The communication is accomplished either 
electrically via contacts or wireless by inductive or capacitive coupling. With this 
method more sophisticated information can be tagged because the presention is 
omitted, as mentioned above. Even information about the current condition of the 
component could be made available, if the IC were equipped with suitable sensors, 
which is summarized under the concept of intelligent components. 

The selection of an attachment method is significantly determined by the 
requirements on the durability and resistance against removal attempts. For 
instance the application of cast-in tags may be preferred over adhesive labels. 

Introducing authenticity in component tagging 

Methods for strengthening component tagging against forgery may be introduced 
in all three of the above abstraction layers. They partly address the authenticity of 
the tagging information or additionally of the component itself. 

On the representation layer the concept of the digital signature as described in 
the first part of this paper may be applied. The signature may replace the tagging 
information completely or supplement it to allow to differentiate between the 
component identification and the signature verification. The latter may be 
accomplished by applying the public key of the signer to the signature. The 
decryption not only firms the authenticity of the signature but also reveals the 
tagging information. The public key may be provided with service documentation 
which is increasingly distributed on digital media. This approach is particularly 
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interesting when using transponder ICs for tagging as they only deal with the 
representation of the tag. 

The presentation of tagging information may be secured by hiding the 
information and must therefore be considered together with the attachment of the 
tagging information. A fairly new companion of cryptography, steganography, 
deals with the hiding of information in other information, in particular text, 
pictures, and audio data. The application on physical components is therefore not 
covered directly but some techniques can be derived. For example, the randomness 
of the least significant bits in raster pictures may be used to hide information. 
Transferred to physical components, the roughness of a non-effective part surface 
may code information, if the surface is intentionally and specifically distorted, for 
instance by laser or electro eroding. The coding can be set up in a more robust 
manner by generating a white noise, transforming it into the frequency space with 
the Fourier transform, adding the tagging information by deterministically 
changing coefficients, and transforming it back. The resulting pattern is applied to 
a non-functional surface in the same manner as above. The advantage of this 
approach is that partial destruction of the surface may still leave the information 
recoverable. The high expenditure makes such a method at least economical 
interesting for expensive and highly security relevant components. 

Another approach could be to slightly but deterministically vary dimensions of 
part features that have no contribution to the parts functionality, thereby adding the 
tagging information. This must of course be accomplished outside of the 
tolerances of the manufacturing process. 

The authenticity of an individual component can be achieved with adding a 
secret to it by simply keeping the method for authenticity verification secret. Such 
a secret could be the acoustical spectrum emitted by the part if excited by a certain 
frequency or frequency mixture. A second example is the explicit composition of 
the alloy the part is made of. It should be made clear that not the measurement 
result itself is the secret but the method by which it was gained, although the 
knowledge of the former could offer additional secrecy. 

A second method is to identify characteristic parameters of the component 
series, measure these parameters for each individual component, and calculate a 
digital fingerprint of the data as described in the first part of this paper. The 
fingerprint may be signed and added to the tagging information. The set of 
characteristic parameters depends on the intended lifetime of component’s 
fingerprint verifiability. For some components the verifiability must only be 
guaranteed until the component has been installed. In this case, parameters could 
be considered which were otherwise subject to signal-to-noise degradations due to 
attrition. 

The set of approaches just presented shall be interpreted as an initial impulse for 
the development of further component and tagging information authentication 
methods. Then one additional secret may come from the unpredictability of the 
engineer’s imagination. 



284 




For details on steganography see Wayner (1997). The yet single conference on 
information hiding was held in Cambridge, U. K. (Anderson (1996)). 



4 CONCLUSIONS 

Product data authentication constitutes a prominent ingredient to the 
establishment of a product’s legally binding digital representation, the digital 
master, not only for enterprise-internal failure tracing but also for long-term 
archiving. The need for authentic product data can also be derived from the 
increase in the geographic distribution of product development processes 
combined with the use of combine- spanning intranets or the Internet and the 
resulting security issues. Thus the efforts for the integration of authentication 
methods in proprietary and standardized product data management and exchange 
structures should be intensified. 

The authentication of product components is a fairly new discipline but will 
evolve swiftly, as the market for fake spare parts in some industrial sectors is 
spreading and the entailed loss of security in the product’s operation will not be 
accepted by the customers. 

The above remarks about product and product tagging authentication indicate 
that virtually any physical effect may be used to transfer and partially store tagging 
information. The time will tell how ingenuity of scientists and engineers combined 
with new manufacturing and measurement technologies may provide us with an 
increase of security in product usage and in the protection of intellectual and 
physical property. 
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Abstract 

In this paper we discuss a new matrix-based modeling technique for flexible 
manufacturing systems (FMS). Four Task Plan Matrices can completely describe 
the job sequencing and resource assignment details of an FMS. The matrices come 
directly from plans generated by machine planners, or from the bill of materials 
and resource requirements matrix. Given the matrices, a rule-based supervisory 
controller operates in real-time to sequence jobs and assign resources depending on 
dynamic situational information about parts available, resources idle, and jobs 
completed. The function of the FMS can be quickly changed when new products 
are needed simply by changing the four matrices. By deriving explicit 
mathematical formulas for p-invariants and the resource requirement matrix for 
generalized reentrant flow lines, NP-complexity problems are avoided, which is 
often an issue in other modeling techniques. 
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1 INTRODUCTION 



For complex manufacturing processes it is very difficult to provide a mathematical 
model suitable for fast redesign of dispatching and routing controllers. In existing 
models (e.g. Petri nets) the functions of the workcell and of the rule-based 
controller are not separated, so that fast reconfiguration for changing goals and 
new products is not easy. Dealing with machine failures, changes in product mix, 
technological changes, changes in goals, etc., requires modifying the controller 
rules in real-time, which is difficult. 

In Industrial Engineering there is a wide variety of techniques available for 
manufacturing scheduling such as the assembly tree [Wolter et al. 1992], bill of 
material (BOM) [Elsayed and Boucher 1994], resource requirement (RR) matrix 
[Kusiak 1992], and sequencing matrix [Steward 1981, Warfield 1973]. 
Unfortunately, these are treated as heuristic aids and cannot provide a rigorous 
mathematical framework as needed for computer analysis and control of 
manufacturing systems. Industrial Engineering approaches such as queuing 
methods [Kumar 1993], Operations Research (OR) approaches [Conway 1967, 
Graves 1984], etc., can provide rigorous analysis and are convenient for 
determining steady-state solutions. Transient analysis and analysis for large-scale 
systems is difficult. 

Rigorous approaches for analysis of discrete event dynamical systems (DEDS) 
are emerging in Electrical Engineering and Computer Engineering. DEDS include 
communication networks, manufacturing systems, Intelligent Vehicle and 
Highway Systems, etc. Available analysis tools include Petri nets (PN) 
[Desrochers 1990, Krogh, 1991, Murata 1989, Peterson 1981, Zhou 1993], the 
max/plus algebra [Cohen 1985], perturbation analysis [Ho 1987, 1989], object 
oriented techniques [Glassey 1990], etc. Unfortunately, it is difficult to provide a 
mathematical model for a manufacturing system that can be used to guarantee 
deadlock-free performance, efficient shared-resource conflict resolution, and 
suitable part-routings. PN are difficult to construct. The max/plus equations cannot 
be written down unless a decision-free PN is available. Finally, computational 
complexity associated with these techniques very often leads to intractability 
[Garey and Johnson 1979]. 

This paper discusses an analytic matrix framework for discrete event 
manufacturing systems modeling, analysis and control. By taking advantage of this 
matrix model, explicit formulae are provided for some useful information 
structures used in analysis and design, thereby correcting the prime deficiency of 
Petri net and other modeling concepts - the inability to provide efficient 
computational techniques. 



2 INTELLIGENT MANUFACTURING 

With the development of automation technology its supporting systems - planning, 
scheduling, a^d control - have gained importance. Fast response to market 
demands and flexibility involves sophisticated control architectures in 
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manufacturing systems. The hybrid nature of FMS and flexibility issues increase 
the role of multi-layer architectures with enhanced sensing, modeling, and 
execution capabilities. All of these concepts are captured by the so-called 
intelligent control (IC) architectures that have been studied extensively in the last 
decade [Antsaklis and Passino 1992, Kusiak 1992, Saridis 1996]. 




Figure 1 Three-level intelligent control architecture. 

A general IC architecture based on work by Saridis is given in Figure 1, which 
illustrates the principle of decreasing precision with increasing abstraction. In this 
figure, the organization level is considered to be the highest level of decision- 
making where the Production Plan (PP), Master Production Schedule (MPS), and 
Material Requirements Planning (MRP) is developed through information 
provided by the marketing department forecasts and upper management plans. This 
level has a role of a manager that schedules and assigns tasks, performs task 
decomposition and planning, and determines for each task a required partial 
ordering of jobs. The coordination level performs the exact job sequencing, 
coordinating the workcell agents or resources. In addition, in the case of shared 
resources it must execute dispatching and conflict-resolution decisions. The agents 
or resources might include automated machine tools, robot manipulators, material 
handling, storage systems and computer hardware for planning, data acquisition 
and decision-making. The execution level contains a closed-loop controller for 
each agent that is responsible for its real-time performance. 

It is shown [Harris et al. 1997] that a task plan produced in the organization level 
is equivalent to four matrices; two of them capturing the information on job 
sequencing and two others describing the assignment and release of resources that 
are needed to perform the jobs. The matrices are passed to a supervisory controller 
in the Coordination level for real-time execution of the plan. 

Based upon the matrix model of discrete event systems [Lewis et al.l993] it is 
easy to design the intelligent rule-based workcell controller. The objective of 
designing the controller is to provide two main functions: (1) job sequencing, (2) 
resource allocation and conflict resolution. The controller design is based upon a 
matrix model of discrete manufacturing systems that is fully consistent with the IC 
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architecture described above. In the next section, the matrix model of discrete 
event manufacturing systems [DBMS] will be discussed in more detail. 



3 MATRIX MODEL FOR DISCRETE EVENT 
MANUFACTURING SYSTEMS 

A new rule-based DBMS matrix model [Lewis et al. 1993] is now described that 
provides a framework for rigorous analysis of discrete event manufacturing 
systems. The matrix discrete model is described by the following equations: 



Logical matrix state equation 

X = F^v; +F/^+ F„m + Fd«d . (1) 

Job start equation 

V, =S,X. (2) 

Resource release equation 

r,=S^x. (3) 

Product output equation 

y = SyX. (4) 

PN transition equation 

m(k + l) = m(k) + W'"x(k + l). (5) 



The matrix state equation is a set of rules, so that it is formally a rule base. 
Bntries of 1 in and respectively indicate jobs complete and resources idle. A 
computed entry x^ = 1 of logical state vector x indicates that all the conditions 
required to fire rule i are met. Bntries of 1 in v^, respectively indicate the jobs to 
be started or resources to be released. The overbar in equation (1) denotes logical 
negation. (Given a natural number vector a , its negation a is such that a (i) = 0 
if a(i) > 0, and 1 otherwise; for instance, job complete is shown by 0 . Overbar 
notation is used similarly throughout the paper). Finally, all matrix operations are 
defined to be in and/or algebra where multiplication is replaced by ‘and’ and 
addition by ‘or’. 

These equations are easy to write down: is Steward’s job sequencing matrix 

(JSM) [Steward 1962], and can be determined from the Bill of Materials (BOM) 
[Blsayed and Boucher, 1994] or the assembly tree [Chakrabarty and Tsao, 1992]. 
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Fv(iJ) = 1 if job j is required as an immediate precursor to job i (equivalently, in 
the BOM, if subassembly j is required to produce subassembly i). is the resource 
requirements matrix of Kusiak (1992), which is assigned by the shop-floor 
engineer, with (i,j) = 1 if resource j is required for job i. The job sequencing 
matrix F^ and the resource requirements matrix F^ have long been used as heuristic 
design aids by industrial engineers, with some possibility for limited analysis (as 
discussed e.g. by Warfield (1973) in the case of F^ and Kusiak (1992) in the case of 
F^). The logical matrix model elevates these design tools to formal computation 
elements. 

The job start matrix and the resource release matrix are additional matrices 
that must be introduced to complete the description of the controller, and they are 
equally direct to write down for a specific DBMS. S^(i,j) = 1 if job i is to be started 
when all the requirements of logical component x. of the decision rule vector x are 
satisfied (i.e., x. is set high). When there are no routings in the system this matrix 
has a diagonal of I’s. In the more general job shop case, it has multiple ones in 
columns, which correspond to job routing decisions. S/ij) = 1 if resource i to be 
released when logical state component x^ is set high. 

Input u and output y represents, respectively, raw parts entering and finished 
products leaving the cell. Input is a conflict resolution input that selects the jobs 
to be initiated when there are simultaneous requests involving shared resources, a 
situation which may occur when the resource requirements matrix F^ has multiple 
Ts in the same column. To resolve such potential conflict and turn the controller 
into a ‘decision-free’ graph [Cofer and Garg, 1992], it is therefore necessary to add 
the extra dispatching control input Uj^, which is allowed to have only one of its 
entries of a given column high at any given instant. 

It is exactly in the selection of the dispatching control input Up that the 
dispatching rules available in the industrial engineering literature [Panwalker and 
Iskander 1977; Elsayed and Boucher 1994] can be used. 

It is important to label the jobs causally in the formulation of the controller so as 
to obtain F^ and in lower triangular form [Warfield 1977]. A causal ordering is 
important also in proving the results on the computation of deadlock analysis 
structures. The components of the rule vector x should then be ordered in 
accordance with the jobs they initiate. This procedure corresponds to numbering 
the jobs from bottom to top in an assembly tree. 

The transition equation (5) together with matrix state equation (1) provide 
complete dynamical description of the system where 



m{k) = 



/.WJ ’ 



( 6 ) 



represents the PN marking vector at discrete event iteration k, and 
W = {Sj-F^ (7) 



represents the PN incidence matrix. 
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4 INTELLIGENT RULE-BASED CONTROLLER DESIGN 



Control of discrete event manufacturing systems (DBMS) [Lewis et al. 1993] is 
examined from a system theory perspective which makes an explicit distinction 
between the plant or workcell (comprised of machines and resources to be 
controlled) and the controller (representing a real-time decision-making scheduler 
in the coordination level which implements a rule base). This rigorous point of 
view is able to provide a design algorithm for discrete event control systems that 
afford a very convenient approach to the design of DBMS. The controller has an 
intelligent rule-based structure and consists of inner loops, where no conflict 
resolution is needed and outer loops, where logic is needed to resolve shared- 
resource conflicts. The DBMS matrix controller design will be illustrated through 
the example. 

Figure 2a depicts an assembly tree, which shows the required sequence of actions 
(jobs) to produce a product. This assembly tree contains information analogous to 
the BOM; it does not include any resource information. 




Figure 2a Assembly tree. Figure 2b Subassembly tree. 



To build a dispatching controller for shop-floor installation to perform this 
particular assembly task, the resources available must be added. Figure 2b shows a 
subassembly tree for the assembly task, which includes the resource requirement 
information. 

Referring to Figure 2a, define the job vector asv = [RlPl BP MIP R1P2 
R1P3 M2P1 R1P4 M3P M2P2 ]\ the input vector u = [PIl PU2]\ and the 
output vector y = [POl P02 ]. The job vector v has two interpretations: as a status 
output of the workcell, it denotes completed jobs; in this role it is denoted as v^. On 
the other hand, as an input of the workcell, it represents the job start command 
vector; in which case it is denoted by v^. Define the controller state vector x, each 
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component corresponding to a unique component of vectors v or y, thus 
representing the initiation rule for the latter. Then, the job start equation and the 
part output equations are: 
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( 9 ) 



Referring to Figure 2b, define the resource vector r as r = [MIA M2A M3 A 
BA RIA PAIA PA2A]^, where ‘A’ stands for ‘available’. Vector r accounts for 
all the resources and pallets in the Bowline. Now, by inspection of the subassembly 
tree, write down F^, F^ and F^, and obtain the controller state equation 
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( 10 ) 

In this equation, row 7, for instance, indicates that component is set high if job 
R1P3 is done and resource M2 is available. To verify this one can formally work 
out the logical operations using deMorgan's rules. 
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The last issue to be resolved in this design is that of resource and pallet release. 
Thus, using industrial engineering experience and Figure 2b, obtain the resource 
and pallet release matrix and write down the resource release equation 



00010000000 
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X ,1 
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X24 

X-,c 



SpX, 



( 11 ) 



where subscript ‘s’ denotes a command to the workcell to start resource release. 

It should be emphasized that and depend only on job sequencing 
information, while all the resource information is contained in F^ and S^. Note that 
rows containing multiple ones in correspond to columns having multiple ones in 
F^. The dispatching input, u^, is needed as a control decision input, since F^ has 
multiple I's in its 2"^* a and 6^^ columns, indicating that machine M2 and robot R1 
are shared resources. 




Figure 3 Petri net representation of the workcell with shared resources. 

It is straightforward to derive the Petri net description of a manufacturing system 
from the matrix model equations (l)-(4). This allows all the Petri net analyses tools 
to be used for DEMS within the matrix model framework. Figure 3, depicts the 
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Petri net model with an initial marking reflecting the number of resources available 
in the workcell (system idle). 

OEMS structure analysis and associated computational complexity issues are 
addressed in the next section. Taking advantage of the matrix model, explicit 
formulas are provided for some useful information structures used in analysis and 
design, thereby correcting the prime deficiency of Petri net and other modeling 
concepts - the inability to provide efficient computational techniques. 



5 MATRIX FRAMEWORK AND COMPUTATIONAL 
COMPLEXITY 

There are many distinct analysis and design problems to be solved in FMS, 
including scheduling with optimality, computation of PN p-in variants to determine 
resource loops, analysis of deadlocks and circular waits, design and 
implementation of deadlock avoidance strategies, and design/selection of 
dispatching and routing algorithms. These problems have varying degrees of 
complexity, which depends on whether one has a flow line, assembly line, or 
general job shop structure. 

The theory of NP-completeness [Garey and Johnson 1979] potentially provides a 
comprehensive approach for analysis of computational complexity in FMS. Many 
traditional scheduling and sequencing problems have been found to be in NP so 
that significant increase in computing power do not significantly improve 
computational capabilities. Thus it has been necessary to develop heuristics or 
approximate methods for analysis and solution. 

Petri Nets have been extensively used in the analysis of manufacturing systems 
with quite variable results. The PN incidence matrix has been used to study 
structural properties of FMS, including determination of the siphons [Boer 1994] 
and deadlock avoidance [Lewis et al. 1996]. However PN applications have not 
fully exploited the matrix nature of the system structure and lead to computational 
intractability. 

The new DE matrix model overcomes one of the prime deficiencies of PN theory 
- it provides rigorous computational techniques for DE systems. As an example we 
select the representative problem of determining the p-invariants for the very 
general class of reentrant flow lines with assembly that allow more than one 
resource to be assigned to job, as well as to assign a resource to more than one job 
in the sequence. The p-invariants have been extensively studied in work by 
[Desrochers 1990], [Jeng and DiCesare 1993], [Zhou 1993] and elsewhere. They 
provide the basis for several FMS control techniques that involve dispatching of 
shared resources. The Matrix model allows p-invariants to be given by an explicit 
matrix formula. 
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Using Petri net terminology, a p-invariant can be defined as a place vector p 
having elements of zeros and ones that is in the nullspace of incidence matrix W, 
that is 



W-p = 0. (12) 

Where W is given by (7) and place vector can be partitioned by vector of job 
places V and vector of resource places r . Now (12) becomes 







which is equivalent with 



w,-v = - w;-r. 



(13) 



(14) 



T 

To find V vectors, multiply (12) by to get the square term on the left side and 
than take its inverse getting 

v = -(Wj -WX-W^-r. (15) 

Now for each particular resource, set the r vector by putting the 1 in appropriate 
row and vector vwill give us the set of jobs contained in the corresponding 
resource loop. Make note that v vectors form a resource requirement matrix (RR) 
[Kusiak 1992] that provides the basis for dispatching of shared resources (MDR 
rule). To obtain the (RR) matrix set r = / , the identity resulting in 

F^=-(W/-WX-W,. (16) 

Every conservative system (very broad class of manufacturing systems have this 
property) has one and only one set of jobs that together with corresponding 

resource form a p-invariant vector. Therefore in these systems, matrix (Wj • W^) is 
always invertible. 

The complete set of p-invariants is given by the columns of the matrix. 



P = 




(17) 



where is the resource requirement matrix, and 7 , the identity matrix. 

To illustrate the formula (17), consider the example in Figure 4.This example 
belongs to the very general class of reentrant flow lines with assembly that allow 
more than one resource to be assigned to job, as well as to assign a resource to 
more than one job in the sequence. 
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Figure 4 Example of generalized reentrant flow line with assembly. 



From (7), 
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Employing now (17) one obtains p-in variants as the columns of: 



(18) 



P = 



Pi 

P2 



P3 

P4 



Ps 

r, 



^3 



1*4 



1*2 r. 

’1 0 1 O' 
0 110 
0 10 0 
0 0 10 
0 0 0 1 
10 0 0 
0 10 0 
0 0 10 
0 0 0 1 



(19) 



Using the formulas (16) and (17) allows one to compute mathematically p- 
invariants and resource requirement matrix for generalized class of flow lines 
where it is very difficult to obtain any results by inspection. 
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6 CONCLUSION 



A new rule-based DBMS matrix model is adopted that provide a framework for 
rigorous analysis and control design of discrete event manufacturing systems. The 
matrices in the matrix model description come directly from industrial engineering 
tools such as the bill-of-materials, assembly tree, and resource requirements 
matrix. By deriving explicit mathematical formulas for p-invariants and the 
resource requirement matrix for generalized reentrant flow lines, NP-complexity 
problems are avoided, which is often an issue in other modeling techniques. 
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Abstract 

The concept of virtual enterprise challenges the way industrial production systems 
are planned and managed. The materialization of this paradigm, although enabled 
by recent developments in communication technologies, computer networks, and 
cooperative systems still requires a full understanding of the processes of 
interaction between companies as well as the design and implementation of open 
support platforms. The reengineering of activities for a networked operation and 
the implantation methodologies considering not only the technical but also the 
socio-organizational aspects must be also taken into account. This paper describes 
the current approach being developed by the Esprit project PRODNET Il\ which 
aims to design and develop an open platform to support industrial virtual 
enterprises with special focus on the needs of small and medium enterprises 
(SMEs). 
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1 INTRODUCTION 



Recent developments in various complementary areas such as communications, 
computer networks, cooperative systems, transportation logistics, and advanced 
information management, represent important enabling factors for emergence of 
new approaches to organize and manage manufacturing systems. In this context, 
networking of enterprises and outsourcing or subcontracting are particularly strong 
tendencies in terms of organization of the global manufacturing and supply chain 
processes. 

The concept of virtual enterprise (VE), as a temporary alliance of enterprises that 
come together to share skills and resources in order to better respond to business 
opportunities and whose cooperation is supported by computer networks, 
challenges the way industrial production systems are planned and managed. The 
advances in logistics, reducing the transportation costs and increasing the 
reliability of the supply flow, changed the meaning of the physical distance 
between the VE members. The main concerns are now related to the 
implementation of a real Electronic Data Interchange supporting the reliable 
exchange of orders, product models, catalog of products, product quality 
information and coordination messages. 

In spite of the mentioned advances, there is a need for faster and more reliable 
communication infrastructures, as well as for a framework for flexible 
interoperation and cooperation between heterogeneous and autonomous nodes. 

This paper describes the current approach being followed by the Esprit project 
PRODNET II, which aims to design and develop an open platform to support 
industrial virtual enterprises with special focus on the needs of small and medium 
enterprises (SMEs). PRODNET II is defining process to allow a gradual migration 
of SMEs towards a VE environment, in such a way to minimize undesirable 
impacts (both technical and social) on the internal side of a company. The 
assumption is that although companies may want to Join a VE on a voluntary basis, 
they want to monitor and control their inclusion and participation in that VE, based 
on their own rules. 

In order to support openness, PRODNET II tries to adopt, as much as possible, 
international standards, a flexible, reliable and configurable coordination 
management, guaranteeing the privacy and autonomy of participating companies. 
Therefore, the PRODNET II architecture is based on STEP, EANCOM, WfMC 
and SET protocol. A detailed description of the PRODNET II architecture can be 
found in (Camarinha-Matos, 1997a 1997c, Afsarmanesh, 1997a, 1997b). This 
paper is mainly focused on the information flows and is organized as follows. 
Section 2 gives a general overview of the PRODNET II platform and architecture. 
Section 3 presents the classes of information and standards adopted by PRODNET 
II. Section 4 discusses the PRODNET approach to orders management, with 
special emphasis on the incomplete and imprecise orders. Management and control 
inside the PRODNET II platform is discussed in the section 5. Open questions and 
conclusions are presented in the section 6. 
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2 THE PRODNET PLATFORM 



Due to many factors (social, market strategy, etc.) is foreseeable to find different 
levels of interoperation between companies in a VE environment. Despite the 
classical way of make business individually is becoming obsolete, this not means 
that companies will start working together in a hundred percent trustworthy way. 
On the contrary, companies are start working cooperatively sharing only a minimal 
set of information. They have to be convinced that public computer networks can 
offer privacy and safety. They are waiting for seeing the results. If the benefits are 
real, companies might visualize a new horizon in terms of business strategy. Which 
means, they probably will be willing to share more information, even resources, in 
a VE environment. This is why PRODNET architecture relies on a gradual 
movement towards the VE environment. 

In a first level, any company will be able to integrate a VE environment based on 
its internal rules. This guarantees a complete independence and autonomy of the 
company. However, if a company wants to share more and be more integrated to 
the environment, PRODNET supports it in a second level of integration. Finally, 
the ultimate goal is to support a VE environment fully integrated, in which 
companies already learnt to trust each other and they also know what to expect 
from a VE, in terms of profits. 

2.1 PRODNET Architecture 

To support this environment and coping with the legacy systems in enterprises, 
PRODNET II proposes an infrastructure including two main modules (Camarinha- 
Matos, 1997b, 1997c): the Internal Module and the Cooperation Layer (PCL). The 
Internal Module represents the autonomous unit of a particular company. It 
includes the complete structure of the company's information (databases, 
information systems, etc.) and all the internal decision making processes / 
enterprise activities (internal PPC and engineering systems). The Cooperation 
Layer contains all the functionalities for the inter-connection between the company 
and the entire net. It represents the communication and coordination role and 
works as the interlocutor of the company within the net (Figure 1). For each node 
of a VE network, PRODNET proposes the following architecture: 



PCL 




Figure 1 PRODNET Reference Architecture. 
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Where the main components are the following: 

PPC - Production Planning and Control System. This is the most important 
component of the internal module of a VE node. It includes functions as: i) 
Industrial Logistics Management: Orders flow management, Product data 
management, Sales Forecasts handling. Actual Requirements Planning; ii) Master 
Production Scheduling; iii) Production Control; iv) Quality Control / Tracking; and 
v) Industrial Costing. 

DIMS - Distributed Information Management System. The Distributed 
Information Management Subsystem in the PRODNET Cooperation Layer is 
responsible to model and manage all cooperation support information 
(Afsarmanesh, 1997a, 1997b). 

EDI Module. This module is responsible for receiving and formatting orders- 
related messages in EDIFACT format. Among its functionalities, it will check / 
parse EDIFACT syntax (for various versions of the standard), check for 
completeness of messages contents, and generate appropriate formats for sending 
out EDI messages. It will also detect and extract EDI messages embedding 
information represented in other formats, such order- associated STEP 
specifications. 

STEP Module. The STEP module’s function is to handle the technical product 
data used within PRODNET. Ideally all product data should be exchanged in 
STEP format. The STEP services provided to PRODNET will allow for the 
transmission and reception of STEP files that have been clear text encoded 
according to a defined schema; as described in Part 21 of the STEP standard. It 
should also be possible to query that STEP data held within PRODNET by the 
usage of the Standard Data Access Interface, SDAI, or via a SQL interface. 

PCI - PRODNET Communication Infrastructure. This module is responsible for 
handling all communications with the other nodes in the network. It includes 
functionalities such as: Selection of communications protocol and channels; Basic 
communications management; Privacy mechanisms (cryptography); and Secure 
message communication channels between nodes. 

Configuration and User Interface. The PRODNET platform is intended to 
support a large diversity of enterprises and interconnection modes. This means a 
large heterogeneity in terms of available / installed services and desired 
management procedures. Therefore it is necessary to specify the desired 
cooperation behavior in an explicit plan (each enterprise has to define its particular 
activity flow plan) that will be “executed”/controlled by the Local Coordination 
Module. 

2.2 Information Handling and Coordination Kernel 

PCL receives all messages coming from and to be sent to the VE environment. 
Every message might flow among PCL modules and it has to be processed 
following a particular sequence of actions, using the data associated to it. A clear 
separation between data and control was adopted inside PCL, based on two 
modules responsible for coordination and data management: LCM and DIMS. 
LCM, a workflow engine based on the WfMC concepts, is the responsible for the 
management/control of all messages inside PCL. DIMS, a distributed federated 
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database module, is the component responsible for managing all data flowing 
through PCL. These aspects will be discussed later, in the section 5. 

A strong cooperation between LCM and DIMS is also the basis to the 
hierarchical workflow approach adopted by PRODNET II to support an 
incremental move of SMEs towards the VE environment. In the first phase of this 
incremental move, a company starts working within a VE according to its internal 
rules. This means a human-supervised control of what to share and monitor what is 
exactly happening in terms of VE transactions. On a later stage, depending on the 
achievement of higher levels of trust between companies involved in a VE, some 
of these processes can be progressively automated. DIMS supports the sharing of 
information among partners, whilst LCM provides control and monitoring of the 
company participation in a VE. 



3 INFORMATION INTERCHANGE 

There are several classes of information to be exchanged between companies in a 
VE. The extent of this interchange depends on the level of cooperation between 
companies. PRODNET is supporting the following classes: 

3.1 Business-related Information 

Orders-related information is the basis of the business-related information 
exchanged between partners in a VE, since the relationships between client and 
supplier are mainly based on orders. Orders-related information includes the order 
data itself but also quality information about the product ordered. Sometimes 
product models and catalogue of products are exchanged as additional information 
to an order. 

Quality information is becoming more and more important in the commercial 
relationships. The customers are demanding better products, in all senses. A client 
may ask for quality certificates from its suppliers. The suppliers do the same to 
their sub-contracted partners and this process goes further and further, along the 
whole supply chain. 

PRODNET II provides EDI-related services to support the exchange of 
commercial information. EDI provides trading partners with an efficient business 
tool for the automatic transmission of commercial data from one computer system 
directly to another. Some companies have been practicing EDI on the basis of 
proprietary formats since the late 1960’s (EAN, 1996). However, an EDI system 
was not a cheap one and it used to take a long time before start running. By the 
mid- 1 980 ’s the development of EDI standards began taking shape within the 
United Nations Economic Commission for Europe. In 1987, the syntax of this 
common business language, known today under the acronym of UN/EDIFACT^, 
was approved as an ISO standard. PRODNET EDI-related services are being based 



^ UN-EDIFACT is the United Nations Rules for Electronic Data Interchange for Administration, 
Commerce and Transport. It comprises a set of standards internationally agreed, directories and 
guideline for the electronic interchange of structured data and in particular the related documents to 
trade in goods and service. 
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on the UN/EDIFACT standard and developed by the Lichen Informatique 
company. 

Nowadays, the EDI standards, although not yet easy to implement, are becoming 
more accredited and popular. Through the use of EDI message standards such as 
EANCOM, data may be communicated quickly, efficiently and accurately 
irrespective of the users’ internal hardware and software equipment (EAN, 1996). 
Moreover, the competition against the HTML-based forms in the WWW world is 
forcing a new commercial vision of EDI, leading to an effort to integrate WWW 
and EDI. PRODNET II follows this approach. 

The EDI protocol can also be used support the exchange of catalogs of products. 
However, catalogs are traditionally based on pictures as well as multi-media 
information. Considering that the WWW world cannot be set aside from the 
PRODNET platform, PRODNET II is also analyzing the use of HTML forms to 
support the exchange of product catalogs. 



3.2 Engineering Information 

This class is based on the Product model information. Some orders can carry 
product-engineering information to better specification purpose. A client might 
want to order a new product or component and a product model is necessary to 
accurately define the requirements. A negotiation process related to a product 
design can be carried out supported by the interchange of these electronic product 
models. The STEP standard provides a normalized way to support the exchange of 
product models. It allows the expression in a uniform and complete way of the 
whole information required for a product during its life cycle, especially through 
the EXPRESS language. Thus, two companies working in the same industrial 
sector can model and exchange their products according to the Application 
Protocol (AP) defined for that sector. 

PRODNET II provides services based on the STEP standard to support the 
exchange of product model in a VE, even if one partner does not have an internal 
CAD tool able to read STEP data. PCL supports the translation to/from STEP data 
from/to native CAD formats. PCL also supports the visualization of STEP models. 
Complementary STEP services are also going to be provided by PCL. The set of 
STEP related functionalities is developed by the CIMIO company. 

3.3 Privacy/Security and Authentication of Exchanged Information 

Reliable and safe information interchange is a key point in any VE. This is a strong 
requirement in order to convince SMEs that making business electronically 
through a public network can be efficient and trustable. Cryptography algorithms 
based on special techniques to assure privacy and security through public networks 
have been adopted, such as symmetric (private-key) and asymmetric (public-key) 
cryptography. Privacy can be guaranteed by the utilization of both symmetric and 
asymmetric cryptographic techniques. 

Authentication is based on a digital signature, which allows the receiver to check 
if the message was changed. Besides that, it can be used to legally associate the 
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message to the sender. The digital signature is also encrypted with the 
symmetric/asymmetric algorithms. 

PRODNET II is offering a communication infrastructure enhanced with both 
privacy and authentication facilities. The ESTEC company and UNL are involved 
in this development. 

In addition to these generic classes of information, there is also information 
related to the VE management that needs to be shared and managed. Examples of 
such information are: company profile, VE structure and access rights of its 
members, public and shared information, etc. The University of Amsterdam is the 
main responsible for the development of a distributed and federated information 
management infrastructure for VEs. 



4 ORDERS MANAGEMENT 

The electronic exchange of orders is a basic functionality to be provided by a VE 
supporting platform. Besides the exchange of the order itself, it is necessary to 
support its follow up in order to cope with, for example, delays in orders 
processing, temporary incapacity of a supplier, changes in not completed orders, 
the need to re-adjust delivery times, and so on. A client company might even want 
to know details about the manufacturing status of ordered products or components 
in order to prevent any difficulties for itself. Orders management is, therefore, one 
of the most important functionalities to be supported in a VE environment. 

In the PRODNET II architecture it is assumed that efficient orders management 
is only possible if a company already has some PPG system which provides the 
company’s internal orders management. Otherwise it seems unfeasible because the 
amount of information required to perform such management should not be 
supported/handled by a component like PCL. Thus, a basic requirement in order to 
accomplish the orders management is a strong interaction between PCL and PPG 
system. This implies some reengineering of the legacy PPG system in order to 
make it reactive to requests coming from the network and to make it able to 
understand the chosen EDI format. 

PRODNET II is also dealing with a very challenging requirement in the orders 
management, that is the ability to support the flow - and the acceptance by 
suppliers - of incomplete and imprecise orders. This is mainly a consequence of the 
need of self- accommodation to rapidly changing markets. Incomplete and 
imprecise orders do not have all information about them defined before starting 
their production process. PRODNET approach to deal with this problem is 
discussed in the next sections. 

4.1 Classes of Orders 

PRODNET II considers three types of orders: Regular, Incomplete and Imprecise. 
There is no information vagueness (incomplete or imprecise data) in a regular 
order, which means all information related to that order is known. On the other 
hand, an incomplete order has at least one piece of data missing, whilst an 
imprecise order has at least one piece of data specified in a vague way. These two 
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types of orders require a special handling process as the data required to fulfill the 
order will arrive incrementally. In spite of the incompleteness or vagueness of 
information, it is often possible for a company to start the production based on the 
available information as well as to propagate that vagueness to its suppliers. 

4.2 PPC requirements for orders management 

The PPC system is the component which embeds the knowledge to manage the 
orders-related messages. Inside the PPC, orders can go through several stages 
along the time, according to their status of accomplishment. Thus, it shall be 
possible to query the PPC in order to know what is exactly happening to every 
single client order at any moment. In PRODNET II an order life cycle includes the 
following main states: 

■ Launched : a new order is received; 

■ Confirmed, the order is confirmed, the production phase can start; 

■ Partially shipped the product(s) required by the order is (are) partially 
shipped to the client, while the remaining part is still in production; 

■ Production: the order is in production; 

■ Fulfilled the order execution is completed; 

■ Cancelled: the order is cancelled. 




Figure 2 Order life cycle diagram. 

Figure 2 illustrates this life cycle. The loop involving the states Production and 
Partially Shipped represents the situation in which part of the required product is 
ready to be delivered to the client as soon as it is ready, whilst the rest of the order 
remains in production. 

An order model is divided in two parts (Figure 3). The first part is composed by 
the General Attributes such as delivery dates, status, quantities, customer 
identification, etc. The second part is composed by the Product Details: product 
identification, invariant characteristics, optional characteristics. One important 
concept related to the Product Details is the representation of a product using two 
different sets of attributes: the invariant and the variant attributes. This 
representation is the key idea behind the management of incomplete and imprecise 
orders, because it is always possible to start the production of a product using the 
invariant part. For example, a car always has wheels, doors, chassis, engine 
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(invariant attributes). But the color and the number of doors are configurable 
parameters (variant attributes), which can be imprecisely or incompletely defined. 



General 

Attributes 



Quantities 
/ ^ Customer Id. 
/ Delivery Dates 



/ 



Product 

Details 






A Product Id. \ 
A Invariant Info 
A Variant Info 




Figure 3 Order Model. 

There are two types of orders, according to the Product Details part. These types 
depend on the way a company is placed in the market or the product it sells. 

One type is related to products that do not have a major component. It is 
important to think in terms of the influence, on the final product, caused by 
imprecision/incompleteness in some of the product’s attributes. 

Let us consider, for example, an order for a car model M, for which it is possible to 
specify particular features (optional characteristics), like the type of engine, the 
color, etc. An incomplete order does not include all required product details. An 
order could, for instance, simply specify a car model M. If an order like that is 
received, then it is possible to start the production of the chassis, the doors, etc., 
independently of the missing information about complementary attributes. New 
“orders” (or messages) are supposed to arrive in future to complement the missing 
attributes in the “original” order (these orders are not really new orders but 
additions to the original one). Thus they should be associated to the original one 
(logically merged). This process continues until all details about the required 
product have been specified. 

An imprecise order is an order in which the value of some attribute is not missing 
but it is specified in a vague way. For instance, in the car example, the attribute 
color, in the initial specification, could say “dark color” or “one of blue, black, 
green”. Only later on this attribute would get a specific (precise) value. Another 
example of vagueness could be on the quantity. An order could specify a tentative 
amount of between 100 and 120 units (to be confirmed later). 

In a second type, the final product has a major component or raw material. In this 
case, it is possible to overcome the imprecision / incompleteness regarding the 
product by forcing a commitment to a precise quantity of that component. This 
type of contract is a common practice in the garment industry. For instance, when 
an order for suits is not precise in terms of quantities and other model-related 
details, it is common to establish a contract in which the client commits himself to 
use / consume a given amount of the main component (a particular kind of fabric) 
independently of the product details to be specified later. PRODNET II is 
considering the ability to handle both types, as an important requirement for the 
orders management. 
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4.3 PCL requirements to deal with orders 

The orders related messages will flow among VE partners coded in an EDI format. 
Thus, PCL has to provide the EDI services to support the exchange of all types of 
orders-related messages. Some services are of general purpose, such as creation, 
identification and parsing of message orders; other services are specific to support 
the management of incomplete and imprecise orders. 

PCL adopted the EAN international standard for EDI communication 
(EANCOM) to support the message orders requirements. EANCOM is a detailed 
implementation guideline for the UN-EDIFACT standard messages. It provides 
clear definitions and explanations which allow trading partners to exchange 
commercial documents in a simple, accurate and cost effective manner. One class 
of standard messages available in EANCOM is Commercial Transaction 
Messages, which covers the general trading cycle from quotation to request to 
remittance advice. This class includes the Purchase Order set of messages which is 
related to the ordering process from a proposed order, subsequent changes and the 
eventual confirmation (relevant quantities, dates, location of delivery, etc.) (EAN, 
1996). In this way, the PCL EDI-related services can cover all orders-related 
requests presented in the previous section, including the management of imprecise 
and incomplete orders. 




Figure 4 Relationship between PPC, PCL and the VE 

Another aspect is related to the conversion from/to EANCOM/PPC internal 
formats. PCL can translate the VE messages to the appropriate PPC format and 
vice-versa. In order to make this task easier, the PPC database, developed by the 
CSIN company, adopted the EDI data definition (Figure 4). 



5 PCL INTERNAL MANAGEMENT/CONTROL STRUCTURE 

PCL management and control structure relies on two major aspects: configuration 
of the PCL behavior and coordination among PCL modules. The former is 
supported by the LCF module. The later requires a clear separation between the 
control itself and the data needed to support the control. PCL receives messages 
from both the company internal module and from other VE members. Each 
message is associated to a specific PCL service. For each message, PCL has to 
know what to do with it, what are the actions that should be performed in reaction 
to the message and how to manage the data involved in the message. 
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Three PCL modules are involved in this process: Local Configurator Module 
(LCF), Local Coordinator Module (LCM) and Distributed Information 
Management System (DIMS). LCF supports the configuration of the PCL 
behavior. LCM is responsible for the coordination among PCL modules. DIMS is 
responsible for the data management and storage inside PCL. 

5.1 Configuration aspects 

The key point in the PCL configuration is the ability to support a gradual migration 
towards a VE environment operation. In a first level, PCL has to guarantee that the 
company’s privacy, autonomy as well as its way of making business will be 
preserved as far as possible. This is provided by LCF module through a flexible 
configuration, based on a strong interaction with a human operator, representing 
the company needs. LCF deals with three classes of information. First, the 
configuration of the company environment is defined in the Company Profile. The 
PCL behavior is defined in the PCL Workflow Model. Finally, the configuration of 
the relationship between the company and the VE environment is defined in the VE 
Network Directory. 




Figure 5 Graphical Workflow Editor. 

The Company Profile represents the information about a company itself, which 
means information about the characteristics of the company’s internal environment 
(such as the engineering systems), about the PCL users inside the company, and 
the customization of the PCL configurable “features”. 

The PCL Workflow Model (PWM) defines the customized way under which PCL 
has to handle the incoming messages. For instance, what are the actions to be taken 
by PCL when a client order arrives. In other words, it defines how a company is 
going to use PCL services. PWM is based on the WfMC^ reference model. A 



^ Workflow Management Coalition Group, a well-known attempt towards the standardization of the 
Workflow Management Systems. 
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workflow model editor was developed, using a graphical language and WPDL 
syntactic/semantic rules were adopted to represent the entities defined in the 
WfMC reference model (Figure 5). PWM is a graph where each branch 
corresponds to a certain PCL service. 

The VE Network Directory contains the information about the VE environment 
itself. In other words, it contains all information about each VE the company is 
involved in, since a company is able to participate in several VEs simultaneously. 
It has two parts (Figure 6): the VE General Information and the Partners Directory 
Information. The first part has the general information about a VE itself. The 
second part has the information about each partner the company has relationships 
with, inside that VE. 



VE GENERAL INFO 




^ VE members' identification 
^ VE general schedule 
^ Access rights over the public 
information - what Is available, 
permissions, etc. 

-f Contract (if it exists) 



PARTNERS DIRECTORY 




> Partners access rights over 
shared information 

> EDI subset (if used) 

> STEP AP (if used) 

> Partners Environm. (PCL / 
other type) 

> Network Information 



Figure 6 VE Network Directory structure. 



Some data must be exchanged during the VE configuration phase. For instance, 
if two companies exchange EDI messages in a VE, there should be only one 
common EDI subset being used by both of them. PCL provides a special EDI 
editor to support the configuration of that EDI subset. To avoid errors and 
duplicated efforts, the subset definition will be made at one company and it will be 
sent to the other one. 



5.2 Separating Data & Control inside PCL 

One important aspect related to the PCL performance is a clear separation between 
the message coiitents and the mechanisms to control the message flow inside PCL. 
As mentioned before, LCM is the module responsible for the coordination among 
PCL modules, and DIMS stores all data handled by PCL. In order to provide a 
suitable separation between data and control, LCM and DIMS modules have to 
work in a strong connection. The data part itself (message content) is stored in the 
DIMS while LCM deals with control using only a key reference to that data. 

PCL internal messages can be classified according to the message purpose. There 
are control messages and the data messages. A control message is used just for 
control purposes, i.e., it has only control information. A data message is used to 
store/retrieve data to/from DIMS. A data message can involve a large amount of 
data, depending on the type of message. A natural consequence of this 
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classification is that LCM only deals with control messages whilst DIMS only 
deals with data messages. 

In order to illustrate what happens when a message arrives at PCL, it is necessary 
to introduce a new module: the PCI. PCI stands for PRODNET Communication 
Infrastructure. It is the module responsible for handling the communication 
services, which involves also the privacy/authentication mechanisms. At this level, 
PCI is only concerned with sending/receiving messages from both internal 
company module and VE environment sides. As mentioned above, PCI has 
adopted international standards related to communication protocols and 
privacy /authentication algorithms . 



PCI ^^WRAPPER*^ 

Message Content (DATA) 



Figure 7 Message structure 

A message arriving at PCL has the general structure presented in Figure 7. There 
are two major parts: the “PC/ wrapper'' and the message content. The “PCL 
wrapper” identifies a message as a PCL message and contains the relevant 
information to be used by PCI privacy/authentication procedures. The message 
content is the data part itself. 

Figure 8 presents an illustrative example to show how a message is handled 
inside PCL: a client order arrives and PCI receives it. PCI removes the wrapper, 
applies the privacy/authentication procedures and send it to the LCM. On its turn, 
LCM stores the message content (data itself) in DIMS and triggers the appropriate 
PWM flow of events to process that message. All modules involved in that flow 
may use the data part stored in DIMS, according to their participation in the 
workflow plan. 



PCL 




Figure 8 Message handling inside PCL (F‘ scenario) 
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However, considering that PCI receives all messages coming from the external 
world, in order to guarantee both authentication and safety of the messages, this 
full cycle should be applied only to messages coming from VE partners; the 
internal messages could go directly to LCM. 

Thus, there is a strong difference between the messages coming from the external 
world and the internal side of the company. No authentication/safety problems are 
expected from the messages coming from PPC and other internal legacy systems. 
Thus, an alternative and optimized scenario is presented in Figure 9. PCI receives 
only the messages coming from VE partners whilst LCM receives directly the 
messages coming from the internal side of the company. Internal format means 
PCIP messages. External format means PECP messages. The separation between 
control and data management follows the same principles described above. 




5.3 Workflow execution and monitoring 

PCL relies on the LCM module to provide the workflow management services. 
LCM is split in two logical components: LCM kernel and LCM monitor. LCM 
kernel is the executor of the PWM, which means it handles the events associated to 
a VE environment according to the PWM definition. LCM monitor allows both 
visualization of and interaction with the LCM kernel during the execution of a 
PWM. Through this monitor, a human operator can: 
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• Visualize all messages coming to the company and sent by the VE partners. 
In other words, s/he can trace all services execution inside PCL; 

• Answer requests from the LCM kernel (for instance, what to do with 
unexpected events); 

• Abort a service execution. 

As mentioned before, a PWM branch is a sequence of activities. In order to 
provide a good monitoring environment during the PWM execution, the monitor 
uses different colors to indicate the execution status of each activity of each 
branch. The activities status are inactive (gray), active (light green), suspended 
(light blue) and pre-conditioned (magenta). Thus, the human operator can know 
exactly what is happening inside PCL: what events are being executed and what is 
the execution status of each one. For example, if one activity has been suspended 
for a long time, he/she can decide to abort that service. 

6 CONCLUSIONS AND OPEN QUESTIONS 

The field of Virtual Enterprises represent a very challenging application area for 
cooperative systems approaches and a new way of organizing manufacturing 
systems. The architecture being developed by the Esprit PRODNET II project 
addresses some of these challenges, offering an open environment for cooperation 
between autonomous enterprises. This paper discussed some aspects related to the 
information flows, including the identification of various classes of information 
that need to be exchanged between members of the VE and a flexible approach to 
coordinate these flows. 

PRODNET II has found strong similarities between VE configuration / 
management and the functionalities of a workflow system (Camarinha-Matos, 
1997c). Furthermore, a workflow management approach facilitates the separation 
between services and coordination / control, facilitating the implementation of a 
flexible coordination environment. Flexible coordination is a requirement to cope 
with the diversity of VE organizations and the evolving nature of the cooperation 
and trust level between enterprises. 

The complexity of the VE area and its large multidisciplinarity, that involves not 
only advanced IT aspects but also the social, organizational and legal issues, raises 
a lot of important challenges that demand further research. One such challenge is 
the design of a hierarchical coordination approach (Camarinha-Matos, 1998). On 
one hand, there are two clearly distinct levels: the global VE coordination level and 
the coordination of the cooperation events inside each member enterprise. On the 
other hand, even inside a single VE member, there are a large number of 
cooperation events to be handled, which require the definition of several sub- 
workflow plans. In order to facilitate the understanding and management of such 
plans the definition of a hierarchy of coordination levels seems adequate. In the 
current implementation, PRODNET II considers three levels. 
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At the very first level, the PCL services are bounded by the PCL itself. In other 
words, the support services providers are the PCL modules only. In the second 
level, the PCL user services are bounded by the company. In other words, the 
legacy systems are considered as support service providers. In the third level, the 
PCL services are bounded by the whole VE. In this case, the VE partners (through 
their legacy systems) are considered as support service providers. 

The interactions between the various levels of this hierarchical coordination and 
the definition of the support services for each level is a topic of ongoing research. 
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Abstract 

Information flow up and down the supply chain, particularly for complex products 
such as automobiles, aircraft, and weapons systems is complex, difficult, fraught 
with errors and time consuming. In the defense business, for example, just the 
engineering trade-off process in the conceptual design phase can take up to a year 
before all the information requested is available for the design engineering team to 
compare alternatives (Schwart97). Some of the problems encountered include the 
inability of small suppliers far down the chain to access technical data created with 
CAD systems to which they do not have access, inaccurate or wrong versions of 
technical data when the supplier eventually obtains it, and difficulty in contacting 
people to request clarification. EDI and geometric modeling standards (e.g. STEP) 
and Email have started to address these problems, but they do not address all of 
them. Email, for instance often results in huge CAD files bogging down a suppliers 
email system (often using a dial up modem) only to have it discarded because it 
was not appropriate to their business. EDI/EC and STEP standards focus on 
standards for the exchange and sharing of data, not on their smooth and efficient 
movement up and down the chain. 

A new approach is proposed which has the potential to eliminate or minimize 
many of these problems. Based on the Systems Integration Architecture described 
elsewhere (Mills95aa, Mills96), it uses the concepts of Distributed Object 
computing, remote computing, Internet access, X-Windows, references and 
associations to facilitate (a) access to remote applications and data and (b) the flow 
of information up and down the supply chain. Details of SI A and an application of 
it, called Aero WEB, to the problems described above are presented. 

Keywords 

Information infrastructure, virtual enterprises, supply chain 




INTRODUCTION AND BACKGROUND 



Manufacturing, defined herein as the overall process by which ideas (or customer 
demands) are converted into products, is undergoing the most radical 
transformation since Ford introduced the assembly line. Substantial changes in the 
way Manufacturing companies operate, the way people interact within those 
companies and the way those companies interact with their customers, suppliers 
and competitors are all occurring. For instance, virtual or extended enterprises are 
forming, operating and dissolving all within a time frame which would have been 
thought impossible a few years ago. Virtual enterprises are formed of core 
competencies of a variety of companies, brought together into a new enterprise to 
meet some short lived market demand (Goldman95). Supply chains are becoming 
extensions of the parent enterprise, forming what has been called “Extended 
Enterprises”. 

These changes are both major problems and major opportunities for 
Manufacturers. As the Next Generation Manufacturing Project puts it: 
“Unprecedented, interrelated changes in the global business environment are 
creating entirely new success factors for industrial competition (Hardt97). 

One significant problem for virtual enterprises and within extended supply chains 
is the integration of their information systems (Adams98). While efforts to create 
standards for geometric data exchange and sharing (e.g. STEP), operating systems 
(e.g. POSIX), computer languages and object message passing e.g. (CORBA) 
(omg98) are underway across the globe, there are also many other existing 
approaches to these same problems (e.g. DXF and IGES for geometric data, 
Microsoft Windows, the Distributed Common Object Model, etc). Consequently, 
the environment in which an organization wishing to form a virtual or extended 
enterprise or to establish a supply chain integrated into their own operations, is 
heterogeneous, where just about everything is different. This is also a fairly 
dynamic environment since the virtual enterprise lifecycle is rarely more than a 
year and often much shorter. Current approaches take far too long to be useful in 
this environment. 

Another problem, which smaller suppliers with multiple large customers face is 
access to, advanced computer technology. To solve the integration problem of their 
particular supply chain, many large companies demand that their suppliers 
purchase the CAD systems that they use. These systems often cost tens of 
thousands of dollars and require advanced computers. A small company with 
several such customers is then faced with having to purchase several such CAD 
systems, but only use them occasionally. 

The research issue intrinsic to these problems is as follows: 

• What is “Integration” in this dynamic, heterogeneous environment? 

A second issue which is a complement to the first in that if we define “Integration” 
appropriately, we can also address it simultaneously, is 

• How can we provide the small suppliers access to the same advanced 
technology that their largest customers have? 
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This paper presents our approach. First we present a basic philosophy or general 
approach which we have called “Integration from the User perspective”, then 
present some of the requirements for a system implementing this philosophy. Then 
an Infrastructure called the Systems Integration Architecture, which supports this 
approach, is presented. Finally some results from applying this infrastructure in a 
demonstration of an engineering trade-off process involving a supply chain are 
presented and the results discussed. 

APPROACH 

Underlying assumptions 

Our basic approach is based on defining “Integration” from the user perspective - a 
user-centric approach. Many of the previous attempts to define integration have 
been based on what we term “implementation approaches”. That is, they have 
focussed on the details of how data is provided to users or how processes should be 
“integrated”. The traditional view of integration of the central database from which 
views of the data were extracted is such an approach. 

Defining integration for the users perspective provides quite a different perspective 
on integration. From the user’s perspective, a user simply would like to have 
access to the data and ftinctions they require to perform their task. They do not 
want to worry about where the data resides, how it is formatted or stored or where 
the application is. They would prefer to have a simple interface, which presents to 
them an icon representing the data, and/or function they need at that point in time 
or a menu with the name of the data or application in it. They would then like to be 
able to access either of these with a simple command (voice or mouse click). This 
is the approach taken within Microsoft Windows and Macintosh. It is perhaps one 
reason why these approaches have so much appeal to the average user. Our 
approach is to expand this concept to data and ftinctions located anywhere on the 
net. 

Requirements 

The first and major requirement for a user-centered, dynamically reconfigurable 
heterogeneous information system is that the user must be able to access data and 
functions without regard to where they are stored, how to access them or what data 
model is used, what data format the data is stored or how, physically (flat file, data 
base, etc), it is stored. 

Note that this requirement makes no mention of such things as reconfigurability, 
interoperability etc, which appear so frequently in analyses and discussions of 
“integrated systems”(Senehi91, Chen93. In our view, this type of requirement is 
imposed because of the implementation view taken. They are almost, but not quite, 
requirements imposed by the approach taken. 

This major requirement has secondary requirements as follows. The system must 
be able to record and keep track of functions and data sets. This record must 
include not only the machine and path where they are located but how to access it 
if it is a data set and how to launch it if it is an application. It must also contain 
other information about the entities that is important for the user and the functions 
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they perform. We discuss integration in terms of functions instead of applications 
because it is a function, which a user needs to perform a task. Applications supply 
functions, usually as an ad-hoc collections. This focus on functions moves us 
towards what Johnson has termed “the ubiquitous service environment” in which 
users will have access to functions anywhere on the net (Johnson96). A function 
can be as small as an applet to add two integers together or as large as a major 
Enterprise Resource Planning system. 

We use the term “data sets” to avoid identifying the data with a particular data 
storage approach (e.g. data base, simple file) or format. A data set is simply a 
collection of data, which is useful at some point in the product realization process. 
We call functions, applications and data sets “integratable entities”, since these are 
what must be “integrated” if we are to have an integrated system. There are other 
“integratable entities” which will be described later. We call the records the system 
must keep about these entities “references”. They are essentially pointers to the 
entity with additional information. 

If the system has to be able to record and keep track of integratable entities, then a 
further requirement is that it must be possible to create, delete and edit such 
references either by a user or automatically. 

Functions require data. Indeed, elsewhere we have suggested that a new basis 
model is needed for “integration”. The proposed basis model, called the 
Transformation of Aspects and Representations model, notes that all software 
simply “transforms” data sets into other data sets of different form or 
type(Mills95b ). This implies that the system must supply some mechanism for 
identifying and storing relationships between the functions and the data sets. This 
is an extension of the idea of an association between the file extension in Microsoft 
Windows and the application, which created it. We also call our relationship an 
“Association” but it is more generic as described later. 

If the function the user requires resides in an application on a computer remote 
from their site, the system must be able to launch remote applications to provide 
the function to the user at their machine. It must also be able to display the output 
of that remote application on the user’s screen. This could be a simple telnet 
session in a window or a full 3-D graphics window session. 

If the data set which the user requires is not on the same machine as the application 
providing the function required, the system must be able to provide a data set to 
that application regardless of the location of the application or data set. The users 
should not need to know how to do this. This implies that the reference must 
contain information on what format, data model and the physical storage 
mechanism, etc the application requires for that data set. 

If the data set is not in the required format, physical storage method etc, this 
requirement also implies that the reference must be able to provide automated 
translation of the data from the format, storage system, etc it is in to that required. 
It should not matter to the user whether the data set is simply in a file or is 
managed by a product data manager. On a side note, we believe that the system 
itself should not provide product data management functions but it must allow for 
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them. We regard the services typical of a product data management software as 
just functions, which a user can use to act on data. 

The system must know what specific data set is appropriate for the application at 
the instant of launch. If a user frequently performs an activity requiring a specific 
function, they may accumulate over time many different data sets, which that 
function, requires. This makes it difficult, if not impossible for the system to 
recognize what data set is required for the specific instance of launching that 
function. The system must, therefore, provide some mechanism for limiting the 
data sets available to that function. 

For some organizations, the management may like to organize the functions into 
specific processes, also called workflow management. The system should allow for 
workflow management concepts, but need not provide workflow management 
functions itself 

Clearly, for a user to access remote functionality and data, any machine involved 
must be physically connected to other involved machines. This implies that the 
system must provide physical network connections between any machine involved. 
A machine can be “involved” by having a user access the system through it, or by 
having applications or data sets reside on it. Further, the system must provide 
communications between these machines. Note that we have not specified what 
kind of communications at this point. 

Technical Approach 

We have been developing an information infrastructure called the Systems 
Integration Architecture (SIA) which meets these requirements and is briefly 
described below. Details are available elsewhere (Mills95a,Mills96). 

Basically SIA is a modular information infrastructure which “integrates” a short 
list of integratable entities. The integratable entities include data sets, functions, 
applications, entities called Functional Transformation Agents, users and projects. 
Applications provide the functions required by the user. In this initial 
implementation we have not made clear distinctions between applications and 
functions. Essentially, at this point we use functions and applications 
interchangeably. Our long-range intent is to provide individual functions from 
applications to move us towards the ubiquitous service environment. Functional 
Transformations Agents or FTAs are objects, which include both the function and 
the input and output data sets. This is the only entity, which is launched by the 
system. The FTA concept provides one way of bringing together a data set and a 
function or application. It is included to implement our ideas that functions 
transform an input data set into an output data set. It also allows us to account for 
workflow management functions in the future but this feature is not yet fully 
implemented. Users and Projects are required to provide context to limit the 
number of functions, FTAs and data sets a user can see at any one time. Thus a 
Project can have many users each of whom has access to only a limited number of 
all the possible functions and data sets which may exist on the system. Each user 
can be a member of many projects, but can access only a limited set of functions 
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and data sets depending on the active project. The reference to each of these 
entities is an object within SI A. 



SIA also allows for Associations to be defined among the References to the 
Integratable Entities. This allows data sets to be associated with functions and 
users, projects to be associated with users, etc, all focussed on “integrating” these 
various entities. 

Figure 1 illustrates the various modules of SIA. The Librarian consists of objects, 
which interface the rest of the system with an object-oriented database. This 
database provides for persistent storage for the references and associations among 
the entities in the system. Note that the Librarian stores only references: pointers to 
entities and information about these entities. In this, it is close to but contains more 
information than the naming service provided by CORBA implementations. 




Executive Buffer 
Subsystem 



Ibatibn'a 5 'Oommurtications. fa 



■ Communications Module 



Figure 1. Modular design of SIA facilitates change 



The Communications Module allows for message passing among the other 
components in the system. Currently it is based on the Common Object Request 
Broker Architecture (CORBA) which allows for - among other services - a 
standardized way of passing messages among distributed objects. CORBA sits on 
top of a physical network which uses both TCP/IP and IPX protocols. Each 
machine in the system is required to have either client CORBA software (for a 
user) or a CORBA server (for applications and data sets). Other distributed object 
message passing protocols such as http. Distributed On-line Linking and 
Exchange, is being investigated. 

The Executive component consists of client CORBA software, which interprets 
actions on the Graphical User Interface to commands, which the other modules 
understand and using IDL, transmits them across the network. The Executive also 
stores certain, frequently accessed, information from the Librarian locally to 
minimize network traffic. Commands recognized by the Executive include: Getlist, 
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Storelist, etc for accessing information in the Librarian, and launch, stop, etc for 
controlling remote functions. 

The User Interface module interprets actions by the user into commands, which 
are sent to the executive. There is one user interface and one executive for each 
user in the system. A user interface can be of any type and in fact we have 
integrated several different user interfaces with the Executive. 

The Launcher or Dispatcher module is a server object based on CORBA, which 
sits on each machine where there is an application or a data set. This software takes 
the IDL Launch message from the system and converts it into a command to 
launch the application. It also checks if that function requires a data set, retrieves 
information from the Librarian on its location and sends a command to that 
Launcher to automatically transmit it over the network. The launcher software 
essentially spawns a new process which then runs independently of the user so that 
the user can let applications run without having to be logged on at all times. 

SIA has been implemented in C++ on Unix Workstations. The Communications 
module uses ORBIX from Iona Technologies and the Librarian is based on 
ObjectStore. It is operational on a Digital ALPHA with the Ultrix operating 
system, a HP with HP-UX, several Suns with SunOs and Solaris, a Silicon 
Graphics Indigo and an Octane, both running IRIX. Access to SIA from PCs is 
currently provided by X-Windows software such as Exceed, which allows the PC 
user to log on to SIA on one of our Unix machines. Various linked X-Window 
User Interfaces, developed in Tcl/Tk allow users to perform the following 
functions: create, edit and delete any of the References to integratable entities; 
associate specific entities with others, launch applications by clicking on FTAs. 
Applications, which have been launched from various machines, include typical X- 
Windows demonstration software such as Xclock, Xeyes, Emacs, and such full 
applications such as AutoCAD, Pro-Engineer, Unigraphics, CIMstation, and 
IDEAS. 

Two separate user interfaces were initially developed for early testing. The first 
was a simple X- Windows based interface developed using Tcl/Tk. This was used 
in early development and testing but has since been abandoned. A second, text 
based command line interface was also developed to allow the developers to test 
various components without the complexity of a graphical user interface. This is 
still in use. These interfaces plus that described below illustrate that the design of 
the system with the executive module separated from the user interface through a 
set of Application Programming Interfaces means that SIA can “Integrate” user 
interface quit easily. 

SIA provides a basic framework for integration from the Users’ perspective. To 
address the problems outlined in the Introduction and to test it under fairly realistic 
conditions, we devised a scenario for the engineering trade-off process across a 
supply chain. This project was called AeroWEB. In this process, the designer 
requests information and quotes from other engineers and suppliers, and requests 
reviews from supervisors. The suppliers request information and quotes fUrther 
down the supply chain. The engineer then conducts engineering trade-off studies 
comparing various alternative designs. To develop the scenario for this process we 
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enlisted a set of potential users including designers, procurement officials from 
several large aerospace manufacturers and several small suppliers to that company. 
In early meetings with these potential users, we identified the processes, which 
apply in the supply chain. Upon analysis, it was recognized that the process of 
requesting information of any kind (quotes, product details, etc) is recursive: a 
person sends out a request (by telephone, email, etc), to a recipient or recipients, 
who either accept it or reject it, perform some activity and then respond. The 
request/respond cycle is identical for anyone in the recursion. Only the data 
required and the activities they perform are different. The activity they perform 
can be to send a request for information further down the supply chain and so on. 
The recursion closes when each person in the recursive chain has responded. A 
particular level in the recursion only closes when all the lower level recursions 
have closed. We also identified the need to allow users down the supply chain to 
request clarification up the supply chain. These clarification requests were also 
identified to be recursive in nature. 

This process recursion turned out to be important because it allowed us to design a 
single set of user interfaces which allows all users to send and receive different 
kinds of data and applications, and to clarify, accept, reject and respond to 
requests. This simplified development substantially. Thus, the adaptation of SI A to 
the needs of an “Integrated” supply chain predominantly focussed on developing 
specialized Graphical User Interfaces. 

The concept behind “Aero WEB” was to send the References up and down the 
chain and to allow users to change the Associations of these References when they 
needed to. No data would be sent up an down the supply chain until it was actually 
required. The user group indicated that often several files were needed, particularly 
when quotes were requested. For example, a request for bid “package” might 
contain text documents describing requirements, CAD files and text terms and 
conditions. We realized that a “package” is a useful concept for the information 
system and that it could be implemented easily as a kind of project within SIA. 
This Package entity contains references to data sets, users and even to applications. 
The project object was modified to allow for this. These “packages” are then what 
is sent up and down the chain. 

RESULTS 

The scenarios 

The purpose of the scenarios was to test the infrastructure under a wide variety of 
circumstances to see if the users definition of “Integration” has been achieved and 
if the approach solved the integration problems across the supply chain. We have 
tested the infrastructure and its services with three related, yet increasingly 
complex scenarios. The first involved a small number of files and applications and 
only three organizations/roles: The designer, a procurement official and a single 
supplier. The collaboration diagram is shown in figure 2. Upon viewing the 
demonstration of this scenario, the user group indicated that the approach had the 
potential for facilitating the flow of information across a supply chain. The 
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demonstration also showed that suppliers using PCs with low cost X-Windows 
software could access the system and launch remote applications like AutoCAD, 
Unigraphics and Emacs to view drawings and textual information without having 
the files on their machines. This demonstration involved files, which were created 
ahead of the demonstration and registered with the Librarian by the students. 
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Figure 2. The collaboration diagram for the first scenario. 



The User group made several recommendations for improvements. These included 
(a) increased complexity of the scenario to make it more realistic, (b) having the 
ability to edit or modify exiting files and to create new files and register them with 
the system, and (c) adding more functionality for the users. 

The second demonstration involved a more complex scenario involving a couple 
more people in different roles within the prime contractor and at least two tiers of 
suppliers. A significant feature of this demonstration was that the degree of 
complexity was increased simply by registering more people with the Librarian 
and assigning them roles. The extra loops in the recursion were added simply by 
sending a package to another user who then forwarded it to a third user, and so on. 
More functions and data sets were added to the system simply by registering them 
with the Librarian and creating the appropriate Associations. This scenario also 
used previously prepared files of information. 

The third demonstration involved more people doing “real” work at each stage, 
with those people registering the files they create with the Librarian before 
shipping them off in packages to other users. Only a few prepared files were used. 
A Chief Engineer review cycle, and several more clarifyAespond cycles were 
added. The collaboration diagram for this scenario is too complex to present here. 
The complexity of the scenario. Figure 3, was easily increased by simply 
registering more people with the Librarian. 

Changing the demonstration scenario requires nothing more than identifying the 
people who will be involved, identifying their roles and adding them to the system. 
The workflow is then controlled by adding the person or persons to the recipient 
list in the package. Adding functions/applications and data sets is also 
straightforward. 
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Figure 3. Illustration of the Final Aero WEB Scenario 



The Aero WEB package user interface has three modes. Figure 4 illustrates it in the 
create mode. This same interface is used for both sender and recipient but it 
changes slightly depending on the state of the system. This figure shows the 
information, which can be included in the package. The details box requires the 
name and the description filled in by the user. The user can also add a message. 
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Figure 4. Illustration of the Package Window in Create Mode 
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All messages added when the package is forwarded are included in this box. In the 
create mode, the Add button under Recipients and Data Sets boxes brings up a 
small window which permits users to add the appropriate person or data set to the 
package. This package is then sent to the recipient by clicking the “send” button. 
The review mode is what the recipient first sees on opening up a package. In the 
Review mode, the only actions the user can take are to open a Data Set, accept or 
reject the whole package or clarify. Instead of the Send and Cancel buttons, the 
Review mode has Accept, Reject, and Clarify buttons. 

The list of entities in the data sets box are all launchable either by the sender - to 
check contents - or by the recipient before they accept the package. This allows 
the recipient to review contents before accepting. The data sets may be on some 
remote machine and the applications with which they are associated can be on a 
third machine. Clicking on the Data Set and then “Open” will automatically 
transfer the file from the machine it is located on to the machine where the 
application is located and launch that machine with that file. In the review/accept 
mode, the Add and Delete buttons under recipients and data sets are muted because 
the recipient can only launch the data sets (and their associated applications). They 
must click on the Accept button before they can do anything more. 

The Accept button transfers the association of the data sets to the recipient and 
allows them to then associate them with other applications they might use. This is 
done in another window, which is not shown here. This action also changes the 
mode of the package window to a third mode called the “Accepted’ mode which is 
discussed below. The Clarify button starts a small window which allows the user 
to enter a small message which is then appended to the package message and the 
whole package sent back automatically to the sender. Note that “Clarify” button 
does not appear on the Create Package Window. In the accepted mode, two of the 
buttons at the bottom of the Review window change to Respond and Forward. 
Clicking on the Respond button allows the recipient to respond to the sender. In 
between accepting and responding he can create his own packages to request 
information or quotes from other people on the system (i.e. sub-tier suppliers), 
register new data sets with the system Librarian and generally perform those 
activities they normally perform when responding to requests. The user can also 
use the Forward button to send the package on to other persons from whom he 
might need help. He can add data sets, and a message to the package before 
sending the package on. Before clicking on Respond or Forward, the user can 
delete data sets and/or add more to the package. For example, they might want to 
add their formal Quotation or a file with the information requested. They can also 
create new packages to enclose the data sets just received and send these on to 
another recipient. 

This Aero WEB application of SIA has been demonstrated on several occasions to 
potential users. The degree of complexity can range form the full blown scenario 
which takes about 20 minutes to a simple demonstration of creating and sending a 
package to user who then launches one or more of the data sets. It has been 
demonstrated within the laboratory environment using the internal network, and 
from a PC logged onto the internal network through both a 28.8kb modem and a 2 
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channel ISDN line. It has also been accessed internationally across Internet by a 
user logging on to one of the machines mentioned above. This last test proved 
quite challenging and identified a number of factors, which had not been 
considered before. However, these users were able to log on, create and send a 
package and launch a data set, both of which, of course, were located on our 
machines. This test has several further steps planned. 

DISCUSSION 

The first question, which must be addressed, is whether the tests under the 
scenarios described demonstrated “Integration” from the users perspective. The 
second question is: Does SIA/AeroWEB facilitate the information flow up and 
down the supply chain and allow all users access to the same software applications. 
To answer the second question first, the users all agreed that such a system would 
indeed make their work a lot easier. 

In these tests, a variety of users on totally different machines at different locations 
were able to create files with different applications and share them with others, 
chosen from lists, by sending packages containing references to them. The 
recipients of the packages were able, by simply clicking on a menu item, to launch 
the application associated with that data file regardless of its location, and 
regardless of the location of the application. The interface of the application 
appeared on the screen in front of the user. At the basic level, therefore, we claim 
that our approach does facilitate the information up and down the supply chain and 
allow everyone to access the same technology. We also claim that our tests did 
demonstrate Integration from the Users perspective. However, there are caveats, 
which must be considered. First, the tests really did not move data sets from one 
application to another. Changes to data sets were made with the application, which 
created it, and these new files were registered with the Librarian and with the 
original application again. To provide full “integration”, the system must allow 
users to associate data sets with other applications which then raises the issue of 
the correct data format and storage and access methods of the data set for that new 
application. This aspect of “Integration” was not tested. We also did not address 
issues of simultaneous sharing (i.e. collaboration) of data files or of data stored in 
other ways such as in data bases. 

Further, the method of registering a new data set with the Librarian and associating 
it with an application is clumsy involving several windows and entering data such 
as the IP address of the machines where it is located, its path and name etc. We 
have realized that that information can easily be acquired automatically and have 
recently tested software that does that. This raises issues in version control and 
naming conventions, which we have not yet addressed. 

A further caveat is that the current version of SIA does not allow applications and 
data residing on PCs to be accessed. We believe that we know how that could be 
achieved and are currently addressing this limitation. For instance, we have ported 
the GUI and Executive to PC and this development is currently under test. 
Another limitation is that we require our dispatcher software and ORB on every 
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machine, which contains an application or data set. Some users may not want such 
expense and may have http or ftp servers available. We have started investigating 
how these different servers may also be included in our view of integration. 

CONCLUSIONS 

We have demonstrated an initial version of a system, which will allow integration 
from a user’s perspective. While not providing “full” integration in the sense that 
we cannot integrate activities into processes, transfer files to different applications 
or accommodate different server technologies, the system does provide basic 
mechanisms for allowing users to access data and applications regardless of their 
locations. We are currently testing the infrastructure or planning test with several 
organizations to see if it can solve their problems. 
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Abstract 

This paper presents the design of a typical virtual enterprise (VRIDGE Inc.), as 
well as an integrated software environment for supporting the design, 
implementation and operation of the virtual enterprise {VRIDGE Workbench). The 
Purdue Enterprise Reference Architecture (PERA) methodology has been applied 
in combination with enterprise modelling tools, and extended with the STEP 




methodology. This has led to the specification of information requirements of the 
Vridge Inc. for developing the Vridge Workbench. 

We have identified three inter-related lifecycles in the design of a virtual 
enterprise. Several modelling tools have been evaluated and utilized. Subsequently, 
a reference architecture consisting of the Coordinator, the Collaborator, and the 
Communicator has been proposed for implementing the VRIDGE Workbench, 
with an aim to improve the effectiveness and efficiency of companies working in 
the global business environment of the 2T‘ century. 
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1 INTRODUCTION 

In the last decade, manufacturing has become global. In order to participate in this 
kind of global business, manufacturing companies need to develop their ability to 
respond quickly to customer’s requirements, cooperate closely with their global 
partners, and participate actively and to be commercially competitive in worldwide 
manufacturing projects. 

The Enterprise Integration for Global Manufacturing Towards 2V^ Century 
(Globeman 21) project has been formed within the framework of the international 
research program on Intelligent Manufacturing Systems (IMS) as an international 
consortium to develop and demonstrate the enterprise integration tools and 
methods to enable a manufacturing enterprise to form a mission oriented project 
enterprise, i.e., a virtual enterprise, for global manufacturing business. 

The Virtual and Real Information Technologies Driven Global Engineering / 
Enterprise (VRIDGE) demonstrator is one of the Globeman 21 projects. It aims to 
develop and demonstrate the life-cycle design methodologies for the virtual 
manufacturing enterprises and their product. The VRIDGE project envisaged a 
global virtual manufacturing enterprise VRIDGE Inc. that carries out the design, 
procurement, construction, and manufacturing of a one-of-a-kind product called 
XFU - a unit of the chemical plant for producing Xylene. 

A virtual enterprise is a loosely coupled enterprise which is formed by many 
partners (whole or parts of real companies) to fulfil a specific mission. The 
motivation for constructing a virtual enterprise is to enable a group of individual 
real enterprises to operate more efficiently and effectively as if it is a single global 
enterprise. As shown in Figure 1, Enterprise Integration is an enabling technology 
for developing a virtual enterprise from isolated enterprises. It consists of the 
methodologies and technologies for virtual enterprise design and operation, as well 
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as the enabling information and engineering technologies for supporting the design 
and operation of the virtual enterprise. 



Local (Real) Global (Virtual) 




Figure 1 Enterprise Integration for Global Manufacturing 

Like any real enterprise, a virtual enterprise can be formally defined in terms of an 
enterprise model, to describe how it is conceptually composed of and how it 
works. However, a virtual enterprise is to be formed quickly to provide a prompt 
response to customer’s requests, a methodology specially for virtual enterprise 
modelling will therefore be essential to support the rapid business development. 
Furthermore, since a virtual enterprise is integrated using advanced information 
technology, one of the major tasks for virtual enterprise modelling will be the 
identification of requirements for product information access and control, as well 
as its enabling information infrastructure. 

This paper presents our findings on design of the virtual enterprise VRIDGE Inc. 
and its implementation as an integrated software environment VRIDGE 
Workbench. The VRIDGE Inc. will be designed, implemented, and operated by the 
VRIDGE project. The VRIDGE Workbench will also be designed and 
implemented to provide a demonstration platform. The experience gained is 
expected to contribute to the development of a virtual enterprise design 
methodology, and facilitate the design and operation of future global engineering / 
manufacturing business processes. 



2. TOOLS AND METHODS FOR DESIGN VRIDGE INC. 

The PERA Methodology 

A recently published book Architectures for Enterprise Integration presents a 
survey on the state-of-the-art on architectures, models, and methodologies for 
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enterprise integration, including an in-depth investigation on three most 
sophisticated methodologies: CIMOSA, GRAI-GIM, and PERA, This project 
adopts the PERA methodology to describe the lifecycle of an virtual 
manufacturing enterprise. The PERA methodology has been successfully used by 
other engineering companies such as the Flour Daniel Inc., USA 

The PERA methodology comprises a generic listing of those tasks which must be 
carried out in a manufacturing plant in order to achieve enterprise integration. The 
model arranges these tasks in a hierarchical functional framework to show their 
proper primacy and subordination to each other. It also shows the necessary data 
flow between these tasks. Figure 2 shows the adopted PERA methodology for the 
VRIDGE project. 
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Figure 2 PERA Methodology adopted in the VRIDGE Project 



Limitations of the PERA Methodology 

None of existing enterprise modelling architectures and methodologies provides a 
complete solution, although most of them are good at certain aspects of enterprise 
modelling. For example, the PERA methodology is good for the “master 
planning”, and it has a detailed implementation guide. However, it does not have 
any tools and methods for identifying the information requirements in order to 
develop necessary software and hardware system to support the operation of the 
VRIDGE Inc. Therefore we will need to extend the methodology in order to 
complement its limitations. 
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Existing enterprise modelling methodologies and modelling tools usually take a 
process oriented approach. However, in order to identify the information 
requirements, we also need to take an information or data oriented view of the 
VRIDGE Inc. One of the best available methodologies in this category is the STEP 
methodology [4] which has been used successfully in the development of STEP, a 
set of international standards for product model data exchange 

Utilizing the information oriented methodology such as the STEP methodology in 
the analysis of product information requirement for virtual enterprise will 
complement and enhance the existing enterprise modelling methodologies such as 
the PERA to form an extended modelling methodology suitable for the virtual 
enterprise modelling. 

Extension to the PERA Methodology 

STEP is an international standard for exchanging product model data. During the 
more than 10 years development of STEP standard, the STEP organization has 
gradually formed a methodology as a means to achieve consistent and integrated 
Application Protocols (APs). The AP defines the context, scope, and information 
requirements of a designated application specific domain, and specifies the STEP 
constructs which satisfy these requirements. 

The STEP methodology provides a guideline for an enterprise to define its 
specification of product information requirements. It also provides a set of 
modelling tools which has been tested and used during the STEP development. 
More importantly, it provides a set of standard resource models which will enable 
the enterprise to develop a product information system to process and exchange the 
STEP conformed product data. 

We adopted the STEP methodology to specify the product information 
requirements for supporting the unique product lifecycle of an individual virtual 
enterprise, the VRIDGE Inc. We also made some necessary modifications to the 
STEP methodology in order to use it as an extension to the PERA methodology. 
The extended methodology is depicted in Figure 3. 
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With this extended methodology, we managed to bridge the gap between the 
modelling of a virtual enterprise and the modelling of an information system for 
supporting the design and operation of the virtual enterprise. As shown in Figure 3, 
the extended methodology uses the enterprise model to define the scope, context, 
and information requirements for the VRIDGE Inc. By deriving the XFU product 
life cycle model from the VRIDGE Inc. enterprise model, and using related STEP 
Application Protocols (AP) such as AP221, AP227, and AP231, we can define an 
activity model for the VRIDGE Inc. to describe the situation where product 
information needs to be shared or exchanged. This activity model can then be used 
to develop an information requirement model which is necessary for developing 
the VRIDGE Workbench to support the design, construction, and operation of the 
VRIDGE Inc. 



Tools for Modelling VRIDGE Inc. 

A formal definition in an enterprise model is needed for defining the requirements 
of the VRIDGE Inc. In order to develop the necessary models as shown on the 
PERA methodology diagram in Figure 2, we have evaluated several commercial 
tools available from the marketplace. A comparison of the selected modelling tools 
and their key features is presented in Figure 4. We concluded that no single 
modelling tool satisfies all our requirements at this moment, and hence we need to 
use a combination of these tools for different modelling objectives. 
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The KBSI AlOWin, an IDEFO based modelling tool, has been used for business 
process analysis and model presentation. The FirstSTEP, a user-friendly enterprise 
modelling tool, was selected for interactive enterprise modelling and simulation. 
The FirstSTEP has also been used to identify the cross company boundary 
information access and control requirements by using its “swimming lane” 
presentation. We also selected METIS as a core modelling tool and model 
repository because of its flexibility, an ontology based model mapping facility will 
be developed in the METIS environment. 
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Internal DB can be accessed by API 
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Figure 4 A Comparison of Selected Modelling Tools 



3 . THE DESIGN OF VRIDGE INC. 

Identification of Related Life-cycles 

According to the PERA methodology, we need to identify the Enterprise Business 
Entities (EBE) which is fundamental for achieving a shared understanding of the 
virtual enterprise. However, we found that there are quite different views on what 
is the business for the VRIDGE Inc. In order to get a common understanding we 
categorized the business entities according to their lifecycles. We identified three 
lifecycles closely related to the VRIDGE Inc., as shown in Figure 5, they include: 

1. The lifecycle of the VRIDGE Inc. (i.e. producer of the XFU Plant), 

2. The lifecycle of the XFU Plant (i.e. product of the VRIDGE Inc.), 

3. The lifecycle of Xylene as a product (i.e. product of the XFU Plant). 

The identification of these three lifecycles helped us to achieve a common 
understanding of the business process of the VRIDGE Inc. where the product 
lifecycle is embedded. It is in this business process (enterprise lifecycle) where we 
can identify the product related activities (product lifecycle), and further identify 
the information access and control requirements of the product lifecycle. 
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Figure 5 Lifecycles related to the VRIDGE Inc. 

The Concept of VRIDGE Inc. 

The identification of lifecycles also helped us to focus on the business process of 
the VRIDGE Inc. In order to have a better understanding of how the VRIDGE Inc 
would operate, we canvassed a process scenario called '‘Success Story” to describe 
the business process from Bidding to Operation and Maintenance. The story also 
defined the roles of business entities identified in the previous phase. 

The "Success Story” has been presented to the industrial people with various 
backgrounds in order to attract their visions on the virtual enterprise. The scenario 
was refined and finally visualized using multimedia technology in order to share 
the understanding of the concept of VRIDGE Inc. Figure 6 shows a scene from the 
"Success Story”. The scenario is also serving as a guideline for the further analysis 
and modelling of the VRIDGE Inc. 

The Enterprise Model of VRIDGE Inc. 

The “Success Story” is used to describe the scenario of the VRIDGE Inc. during 
the enterprise modelling using the FirstSTEP package. The names of major 
business entities, such as the names of all participating companies, personnel 
resources, products, activities, and major information flows, are all derived from 
the “Success Story”. It is quite straightforward to define the higher level enterprise 
business process based on the textual scenario description. Figure 7 shows a 
snapshot of the FirstSTEP model of the VRIDGE Inc. 
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Figure 6 A Scene from the Success Story - Working with VRIDGE Workbench 



4. THE DESIGN OF VRIDGE WORKBENCH 

One of the major aims for the analysis of requirements for virtual enterprise is to 
develop a system to support the design, construction, and operation of the virtual 
enterprise. We called this integrated software environment as VRIDGE Virtual 
Enterprise Workbench, or VRIDGE Workbench in short. Such a workbench can be 
used by manufacturing companies to rapidly develop and effectively manage their 
global manufacturing business. 

Requirements for the Workbench 

Generally speaking, the workbench is expected to provide tools and methods to 
help the company to team up a mission oriented virtual enterprise with specialists 
distributed all over the world, to pull together accurate information and knowledge 
in a very short period to secure an order through a highly competitive bidding 
process, and to substantially shorten the time for passing on the information to 
those involved in the subsequent design, manufacturing, and maintenance phases 
with advanced product information access and control system. The workbench will 
also serve as the corporate knowledge base, the product information center, and the 
business contact point for the virtual enterprise. 
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Architecture of the VRIDGE Workbench 

According to our analysis of the requirements for the VRIDGE Inc., we have 
identified that such a workbench should support the project management and 
coordination, the product information access and control, as well as the daily 
communication. An architecture has been proposed for the VRIDGE Workbench to 
address these identified requirements. It consists of three major functional 
modules: the Coordinator, the Collaborator, and the Communicator, as shown in 
Figure 8. 



Functional Modules of the Workbench 

The Coordinator, Collaborator, and Communicator together form an integrated 
workbench for supporting the design, construction, and operation of the VRIDGE 
Inc. The Coordinator will support the virtual enterprise design and operation; the 
Collaborator will support the product development and assist engineers and 
managers to control product information; and the Communicator will serve as a 
communication center for all engineers and managers within a local company and 
among globally distributed partners of the virtual enterprise. 
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Figure 8 Architecture of VRIDGE Workbench 

The Coordinator 

The Coordinator will consist of four major functions: 

1 . The Enterprise Design Platform for analyzing, modelling, and simulating the 
virtual enterprise business process and information flow. This sub-module 
will be implemented by integrating existing modelling packages such as 
Metis. Necessary user- and data- interfaces will be implemented, and the 
extended enterprise methodology will be implemented into a multimedia 
tutorial system and an on-line help system to provide guidance to the virtual 
enterprise design. 

2. The Partner Profile System for managing all the necessary information about 
potential partners who may participate in the virtual enterprise. It will also 
manage the protocols for coordinating the business processes, such as 
Request for Change, Design Review, etc. 

3. The Project Supervising/Monitoring/Supporting System for project 
management and coordination. It will support the operation of the virtual 
enterprise and provide a transparent interface between partners. 

4. The Risk Management System for controlling potential risks involved in the 
operation of the virtual enterprise. The commercial risk management tools 
will be incorporated into the workbench. 
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The Collaborator 

The Collaborator will also consist of four major functions: 

1. The Change Management System for issuing and approving the Requests for 
Change during the product development. The system will then select a proper 
protocol for change management through the Partner Profile System, and send 
out the request through facilities provided by the Communicator, such as 
Secure E-mail or CORBA. 

2. The Product Information Exchange Management System for deriving or 
converting the product information from one format to another. STEP based 
interfaces will be used to access and dispatch the product data stored in the 
STEP Data Warehouse. 

3. The Access Authorization Management System for information access 
control. The system will manage everyone’s access right to the confidential 
information such as the product data according to the advice from Partner 
Profiles System. 

4. The Model Presentation GUI for visualizing various models. The GUI will 
provide a set of interfaces for presenting the enterprise models, product 
models, as well as 2D and 3D product model data. 



The Communicator 

The Communicator will provide general communication tools which will be used 
by human users and other functional modules of the Coordinator and Collaborator. 
The EDI Interface and CORBA platform provide necessary facilities for Internet 
based computing and communication. The Secure E-mail system provides a 
reliable method for delivering confidential information such as the bid. The WWW 
Service provides a versatile platform for on-line discussion, design review, as well 
as information searching and browsing. The Change Reminder sends immediate 
alarm to the related people whenever a change is registered. The Desktop Video 
Conference System provides a real-time meeting platform over the network 
serving as an alternative to the face-to-face meeting. 

The Communicator manages two databases for the workbench. The STEP Data 
Warehouse manages all STEP confirming product information which is created, 
modified, and used during the operation of the VRIDGE Inc., while the Reusable 
Model Repository manages all kinds of reusable models which are created before 
or during the design and operation of the VRIDGE Inc. 

Implementation 

The proposed VRIDGE Workbench will be implemented in two phases. A proof- 
of-concept workbench is currently being implemented, and expected to be finished 
by the end of 1998. This proof- of-concept implementation will then be used for 
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experiment and gathering feedback from users. After necessary refinement, the full 
scale workbench will then be implemented and used to demonstrate the design, 
construction, and the operation of the VRIDGE Inc. 
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Abstract 

An extended enterprise is formed in the Globeman 21 project of the international 
Intelligence Manufacturing Systems Initiative to investigate the problems involved 
in the information access and control within the extended enterprise. Since the 
relationship of the companies in the extended enterprise is loosely associative, that 
is, there is no formal legal binding mechanism to explicitly state the obligations of 
the partners, the information infrastructure must also reflect the openness that is 
required to support it. This paper discusses the development of such an 
Information Infrastructure and some of the work done in ascertaining the usability 
of the technologies adopted. Specifically, we discuss various policies and software 
structures, and evaluate the use of WWW versus Lotus Notes in such an 
infrastructure. 
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1 BACKGROUND 



Manufacturing enterprises are moving towards global operations. The extended 
enterprise is formed when several organisations join forces to work towards a 
common goal (Goldman et al, 1995). These organisations share investigative 
experiences in information sharing. They discuss issues related to organisation, 
access, control and compatibility of information within the context of operations in 
the extended enterprise. 

The information technology infrastructure is designed to support the operation 
of an extended enterprise known as VRIDGE, which is the acronym of Virtual and 
Real Information Driven Global Enterprise. VRIDGE aims to demonstrate that the 
design and construction tasks of one-of-a-kind products can be successfully carried 
out by a group of companies loosely associated with one another in the global 
environment irrespective of the geographical and cultural barriers. 

A lot of research has been devoted to study to set up an effective management 
system for information and technology within an organisation (Sarkis et al, 1995; 
Spiegler, 1995). More research is required, however, for determining an 
appropriate information system architecture for the extended enterprise. In this 
project, VRIDGE makes use of product modelling standards, enterprise reference 
architecture and system engineering principles to achieve its goal. These 
methodologies are integrated as a Extended Enterprise Workbench which helps the 
extended enterprise to pull together accurate information and knowledge in a very 
short period for various business tasks. 

The intelligence of the processes in the extended enterprise will require strong 
support of the appropriate information technologies (Konig et al, 1994, 
Kadobayashi et al, 1992). This research project evaluates information 
technologies from the viewpoint of how to apply them in business processes. 
Reference models and prototypes are proposed as a results of analyses and trials. 
Considering the rapid evolution of information technologies, the development will 
be fairly swift. The approach adopted therefore aims to be evolutionary, bringing 
useful results together in a step by step manner with existing systems. 

The paper is organised as follows. Section 2 presents the policies adopted to 
govern the development of the infrastructure. Section 3 evaluates Lotus Notes in 
relation to the policies. Section 4 describes development of an open infrastructure 
based on WWW. 



354 




2 POLICIES 



In order to unify the activities of partners in the virtual enterprise and simplify the 
synchronisation work that needs to be done, information technology policies are 
formulated to provide guidance for the design and implementation for the 
development of the Information Infrastructure. 

2.1 Information policies 

The information that will be exchanged on the communication media will be 
secure and authenticated. The use of distributed database will be minimised to 
reduce risks of information leaking. The security of communication will be 
guarded by encryption, by means such as public key encryption algorithms or 
secret key encryption algorithms. Digital signatures based on encryption will 
protect against spoofing and illegal modification of the data. 

2.2 Operation policies 

The wide spread application of the Internet and public networks such as ISDN, 
high speed telephone modems in recent years has enabled a low cost and effective 
way of transporting information globally. An open network can be constructed as 
shown in Figure 1 . 



Mobile 




Figure 1 Open Network. 

In the future, ATM (Asynchronous Transfer Mode) is anticipated to be the 
next generation lower level communication method to broaden the bandwidth on 
fibre or cable. Development of VRIDGE Information Infrastructure on the 
Internet will therefore ensure that the system can naturally adapt to the next 
generation technology. 
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By maintaining an open network, clients can enter the system at any time and 
at multiple points of the plant design. The operation will be distributed and the 
work environment will be collaborative and remote. 

2.3 Design policies 

The Information Infrastructure will use object oriented technologies, version 
control and dependent information will be maintained. The existing information 
management technology is capable of managing only alphanumeric data. Unlike 
alphanumeric data, data such as images, video, drawing, charts, etc. are not of 
much use unless the application-specific semantics or content-based interpretation 
embedded in such data is extracted, represented, and manipulated by an 
information management system. In other words, visual and audio information 
processing and understanding systems need to be integrated in a multimedia 
information management system. 

Presence of multiple types of data also requires media integration. In brief, the 
existing information management technologies need to be extended, or new 
technologies need to developed, for the management of multimedia information. 

In addition, the way information is presented to users needs to be considered 
to enhance human communication and interaction. The goal here is to develop 
multimedia interfaces that can combine voice, video, graphics, and other formats, 
and display the data to an operator in the most effective manner. 

2.4 Technology policies 

Standards such as STEP and the related tools will be used wherever possible to 
ensure proper information exchange. 

Commercial Computer Supported Collaborative Work (CSCW) tools are 
preferred to minimise development costs. Such tools include video conference 
tools with audio and white board on workstations or PC. Video conference 
systems are easy to operate and require only action and voice, which compare 
favourably to E-mail. However, they require substantial network resource and 
real-time transfer. Recording and replaying mechanisms on these tools are to be 
considered too. 

Another solution is a group annotation system that supports annotations to 
documents anywhere on a network shared by people in a group. Many 
synchronous and asynchronous collaboration tools are emerging, and these are 
evaluated from the point of view of how to apply them most effectively in business 
processes and how they can provide innovation in business processes. 
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2.5 Security policies 



All operations are performed with the presence of company firewalls. A firewall 
protects the network from invasion, control of access to data determined by user 
level, and reliability of the network and servers. A typical arrangement for such 
kind of firewalls is shown in Figure 2. 



Router 




Figure 2 Firewalls integrated with public and private networks. 

The use of firewall presents a lot of difficulties in the transfer of the 
information. Packets, irrespective of whether they are useful or not, if they come 
from unknown sources, the firewall will not allow them to go through. This means 
in an extended enterprise situation, new companies will have unnecessary hurdles 
to overcome when they join the Information Infrastructure. A lot of work will be 
required to investigate methods to maintain both requirements (security and 
openness). 



3 SOFTWARE STRUCTURE BASED ON LOTUS NOTES 

The software structure should be open and flexible for future development. 
Current constraints such as the firewall have been recognised by the enterprise 
policy and must be maintained properly. New technologies have been investigated 
in this project to determine their suitability to be implemented as part of the 
Information Infrastructure. 

Figure 3 shows the software structure of a preliminary design of the 
Information Infrastructure. 
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Figure 3 Initial software structure. 

The system is designed around the use of Lotus Notes and taking into account 
the need for CSCW, email, Web browsing and information passing. Based on this 
software structure, a series of experiments have been carried out to ascertain the 
advantages and disadvantages of the structure. 

3.1 Viewing of non Web based documents 

A primary concern in the design of the Information Infrastructure for VRIDGE is 
the ability for the user to browse the information freely, irrespective of the format 
of the information. 

One experiment on Lotus Notes was to test the portability of the information 
which was held in different format (Figure 4). 
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Figure 4 Experimental Lotus Notes. 

In this configuration, the Domino server converts the Notes document from 
the Notes database to HTML format so that the user can view it using a Web 
browser. Hence, there is no restriction of the document type applied to the viewer. 

3.2 Functional areas supported by Notes 

The experiment on Lotus Notes was carried out on 5 functional areas: 

• Electronic bulletin board 

• Authorisation work flow 

• Discussion 

• Connection to the Internet 

• Remote connection 

The electronic bulletin board handles wide variety of documents such as 
images, sound and normal documents. Access control by levels of display. 
Particular field of the document can be undisplayed. Documents can be searched 
without making Index Database. 

When documents are required to be authorised, Lotus Notes includes the 
approval of electronic signature from responsible personnel. Similarly, 
notification of meeting automatic notification of long absence. 

Access control level can be set for individual users in Lotus Notes. However, 
attributes of document for Web browsing cannot be set making it difficult to 
customise to individual use. 

3.3 Problems of Lotus Notes 

Lotus Notes is a proprietary system which does not work cooperatively with third 
party software. However, for setting up information system within an “extended 
enterprise”, since each partner organisation is an autonomous entity, there is no 
guarantee on the other partner enterprises that Lotus Notes is available. In other 
words, the fundamental requirement within VRIDGE is openness which 
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contradicts the characteristics of Lotus Notes. Furthermore, Lotus Notes is also 
difficult to customise and there is serious limitation to the 64k memory model. 
There also can be confusion between the Lotus Notes language (Expression) and 
Visual Basic and is difficult to program. 



4 OPEN INFRASTRUCTURE ON WWW 



The experiments on Lotus Notes reveal the need for more open system architecture 
and components for the proper operation of the extended enterprise. The new 
system architecture is designed based on the application of Web technologies and 
generally assumes that access to the Internet is easy and low cost. 

4.1 Java 



Java is a computer language designed with Internet applications in mind. A 
program written in Java can either be executed as a resident computer program in a 
local Java environment or as an applet downloaded from the Internet. In the latter 
case, the program is activated via a Web browser. In both case, the Java program 
are in fact almost identical. 

The experiment on Java is centred around whether it is allowed to access to 
the documents on the network. An initial test was carried out using a local Java 
applet communicating with a local Java program to save the information to a 
client’s disk. The system was able to communicate with the server through the 
firewall (Figure 5). 



Server 



Firewall 



Client 




Figure 5 Java experiment. 
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Firewall 




Figure 6 Java programs with security. 

The situation at present has been attained relatively easily. The client has 
been declared as a trusted host. However, to cater for the need of any customer, it 
is imperative to ensure that the future situation can be attained too. Investigation 
on the use of special mechanism to enable the Java programs or applet to work 
through firewalls is currently carried out. A typical scheme is to use formal 
security mechanisms as shown in Figure 6. 

4.2 CORBA 

CORBA stands for Common Object Request Broker Architecture. It is designed 
for the integration of objects in an open architecture using broker concept. Two 
software systems supporting CORBA applications were tested in the experimental 
environment. The main purpose was to determine the conditions and application 
environments for this type of technologies to be used. The two systems were 
Orbix and VisiBroker. 

The experiments found that the two systems were largely similar in functions. 
The current experiments are basically centred around the question of how client 
and server functions can be separated into two programs running on 2 hosts. The 
initial trials are successful and the advantage of network computing is apparant. 

However, when it comes to some critical functions, especially when several 
applets and some other communicating parties are involved, security violations 
often occur. While good system design can generally avoid such violations, the 
effort to ensure the security rules are being observed seems to be excessive when a 
large number of hosts and clients are involved. 

Moreover, these CORBA systems are not source code compatible. Programs 
written in one system cannot be compiled in the other system immediately unless 
substantial manual editing is done. Hence, selection of the right CORBA vendor 
with some critical functions is important to ensure effort is not wasted at later 
stage. 
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4.3 Talk Room 



The partners in Globeman 21 have initially used a WWW facility to encourage 
people to discuss issues without the use of Email. Talk Room is an 
implementation of WWWBoard discussion forum and message board on WWW 
plus FTP. Messages from the partners are stored automatically to the central 
server in a hierarchical manner so that related messages are grouped together. The 
facility was found very efficient initially for brainstorming ideas and clarifying 
specific issues. However, the system becomes overloaded and messages are 
difficult to be located after a while. 



5 CONCLUSION 

Investigations made by the Globeman 21 partners to define an open information 
infrastructure for extended enterprises show that the WWW on the Internet is an 
efficient and easy to access system. However, there are many issues, especially in 
data and functional security areas where the partners have made significant effort 
to find an acceptable solution to suit the volatile extended enterprise structure. 

In general, information which are organised on a WWW server in HTML 
format can be shared among partners easily. All partners in VRIDGE have 
standard Web browser facility which can access the information on the WWW 
effectively. When more complicated operations are required, applets which 
operate with Java/CORBA components can be developed. Due to complexity 
involved, current experiments are conducted without security mechanisms. In the 
future, it has been planned that public security key systems such as PGP or SSL 
can be used to ensure the integrity of information transmitted through the 
Information Infrastructure. 
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Abstract 

We present an experiment in modelling and analysis of an application domain: 
competitive manufacturing. The result is a unique formal model which combines 
previously separate models for marketing (competition) and enterprises 
(coordination). In particular, we capture formally the marketing mix: product, 
price, place and promotion, and its effect on the sale of the enterprise. The model 
is built in stages: market without marketing, marketing without limits and 
marketing under limited resources. Analysis includes justifying abstraction, down 
to two enterprises competing for a single consumer. 



Keywords 

Enterprise Modelling and Integration, Marketing Analysis, Extended 
Enterprise, Formal Modelling, Property-Preserving Abstraction. 

1 INTRODUCTION 

The work on modelling of manufacturing enterprises has been traditionally divided 
between modelling for competition and for cooperation. The first has been 
exploited for many years now, receiving, not unsurprisingly, a lot of commercial 
interest and producing many quantitative theories for consumer behavior, market 
segmentation, demand assessment and forecasting, pricing, advertising and many 
others (Kotler 1991). Technically, the models are mostly sets of equations (e.g. the 
equation between price and demand), analyzed using methods from statistic or 
linear or non-linear algebra (Kotler et al. 1988). The second area is more recent. 




appearing soon after CIM itself (Teicholz et al. 1987), and aiming at better use of 
resources and coordination of activities within and between enterprises (Petrie 
1992, Vernadat 1996). Here models are more about behaviors than numbers. They 
describe the resources owned by the enterprise as well as processes which utilize 
such resources. They own more to methods of specifying and verifying software, 
more expressive and usually capable to include methods from statistic or algebra. 
Examples of frameworks for enterprise modelling and integration (often called 
‘reference architectures’) include: GERAM (Bernus et al 1995), CIMOSA 
(AMICE 1993), GIM (Roboam et al 1989), PERA (Williams 1994), ARIS (Scheer 
1992). 

This work is a case study in the integration of enterprise and marketing models. 
There are many reason one may like to seek such an integration: (1) Realistic 
representation of constraints upon marketing decisions made by the firm: its 
resources and how they are allocated to business activities. Such constraints are 
typically written as parameters to marketing equations, unable to capture their true 
behavioral and dynamic nature. (2) Providing a clear goal to the integration effort, 
not for its own sake but to compete better with other enterprises. On their own, 
enterprise models come with no method of assessment of the integration efforts 
and therefore without a clear sense of direction. (3) Methods to model enterprises 
are now being extended to collections of enterprises which to some extent 
cooperate and to some extent compete with each other, forming an extended 
enterprise. Modelling requires addressing both issues together. We can better 
exploit opportunities for information-sharing and joint decision-making within the 
extended enterprise if we can make enterprise models and models for marketing 
analysis “work together”. 

There are many open issues when it comes to the integration of enterprise and 
marketing models. By presenting this case study we hope to put forward and 
clarify some of them. We focus on one scene: a set of enterprises, all 
manufacturing one product, competing to take the best share of the demand 
generated by a set of consumers. Enterprises advertise the attributes of their 
brands of the product, price among them. Consumers assign weights to the 
attributes and buy according to the calculated utility of each brand. Within each 
enterprise decision-making involves the choice of the marketing mix: product, 
price, place and promotion, under the limitations imposed by the enterprise 
resources. We consider three stages in the design of the model: (1) Market without 
marketing: enterprises are able to sell products on the market but cannot by 
themselves increase the sale. (2) Marketing without limits: enterprises can make 
decisions by which they could increase the sale, constrained only by their 
competitors. (3) Marketing under limited resources: enterprises can only make 
marketing decisions within their capacity to implement them. 

The stages are considered in Sections 2, 3 and 4 respectively. Section 5 is about 
abstraction and Section 6 contains conclusions. Throughout the paper we apply the 
formal notation of RAISE (Rigorous Approach to Industrial Software Engineering) 
and its specification language RSL (The RAISE Method Group 1992). 
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2 MARKET WITHOUT MARKETING 



Consider a single product and a number of players on the market for this product, 
some willing to buy and others to sell. We declare them as abstract types, with 
functions to buy and sell products (we ignore for now constraints). 

type 

Consumer, Supplier 

value 

buy: Nat x Consumer -> Consumer, 
sell: Nat x Supplier -> Supplier 

A market is a set of players where consumers and suppliers can simultaneously sell 
and buy (one-to-one) products. represents partial functions, pre represents a 
pre-condition, post a post-condition, and I is a union of types: 

type 

Player = Consumer I Suppher, 

Market = Player-set 
value 

one to one: Nat x Consumer x Suppher x Market ^ Market 
one_to_one (n,c,s,m) = m\{c,s}u {buy(n,c),sell(n,s)} pre {c,s} c m 



Consider a transaction between a consumer and a set of suppliers. Partition 
represents different ways to partition demand between suppliers: all partial 
functions that given a natural number (a demand), a consumer and a market return 
a map from suppliers to natural numbers (a share of the demand). Partition is 
defined as a sub- type, a type constrained by a predicate is_wf . dom represents a 
domain and rng a range of a map. 

type 

Partition’ = Nat x Consumer x Market ^ (Supplier Nat), 

Partition = {| p:Partition’ . iswf(p) |} 

value 

iswf: Partition’ -> Bool 

iswf(p) = (Vn:Nat, c:Consumer, m:Market . 

dom p(n,c,m)=suppliers(m) A sum(rng p(n,c,m))=n ), 
suppliers: Market -> Supplier-set 
suppliers(m) ={s | s:Suppher . s e m} 
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A many-to-one transaction is a function with four arguments: demand, consumer, 
market and partition. It returns a new market by transferring products between 
suppliers and a consumer, subject to specified partitioning. 

value 

many_to_one: Nat x Consumer x Partition x Market ^ Market 
many_to_one(n,c,p,m) = (m\{c}\suppliers(m)) u {buy(n,c)} u 

{sell(p(n,c,m)(s), s) | s: Supplier . s e m} pre c e m 

Two distinctive ways to partition demand are: equally or in random. Both can be 
represented by values of type Partition, giving rise to the corresponding 
transactions. But none allows players to influence their share of the demand. 

value 

equal: Partition . (Vn:Nat,c:Consumer,m:Market . 

(V sl,s2:Supplier.{sl,s2}em => 
equal(n,c,m)(sl) = equal(n,c,m)(s2)) ), 
random: Partition . true 



3 MARKETING WITHOUT LIMITS 

A number of variables controlled by the enterprise affect the level of demand for 
its products. These called marketing-decision variables are typically classified into 
four P’s (Kotler 1991): product, price, place and promotion. This section provides 
a simple model for advertising that captures such variables. 

3.1 Advertising 

Suppose each brand of a product is assigned different attributes like price, 
reliability, service, efficiency, aesthetics etc. Suppliers advertise the levels of such 
attributes. Consumers assign weights to them according to how they perceive their 
importance. Weights and levels let them calculate the relative utility of each brand 
and therefore partition the demand proportionally. 

Formally, assume a type of attributes with one distinguished attribute price. 
Function attribute produces the levels of attributes for every supplier, 
represented by real numbers. Function weight produces the weights of attributes 
for every consumer. 
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type 

Attribute 

value 

price: Attribute, 

weight: Consumer x Attribute -> Real, 
attribute: Supplier x Attribute -> Real 

Together, the functions allow consumers to calculate the utility of products by 
different suppliers, by summing up the multiplied levels and weights of all 
attributes. This may involve some normalizing in order to be able to actually 
compare values of different attributes, taking some attributes proportionally and 
some inverse-proportionally (price) etc. In essence, however, we have the 
definition of the utility function utility and function total which sums up 

utilities for the set of suppliers, as below. 

value 

utility: Consumer x Supplier Real 

utility(c,s) = sum ({attribute(s,a) * weight(c,a) j a:Attribute . true}), 
total: Consumer x Supplier-set -> Real 
total(c,ss) = sum( {utility (c,s) | s:Supplier. s e ss}) 

Then utility (c, s) /total (c, ss) is the relative satisfaction of the 
consumer c when purchasing products from the supplier s, and given the levels of 
attributes advertised by all suppliers ss. comp represents the value of type 
Partition where shares received by different suppliers are in the same 

proportion as relative satisfaction for their brands. 

value 

comp: Partition . (V c:Consumer, s: Supplier, n:Nat, m ‘.Market . 

{c,s} c m => let ss = suppliers(m) in 
comp(n,c,m)(s)/n = int (utility(c,s)/total(c,ss)) end ) 

As an illustrative example from the car industry, take four brands of the Japanese 
cars: Mitsubishi, Honda, Toyota and Nissan, advertising five attributes of their 
economy cars: price (in Peso as in the Philippines), reliability (number of “good” 
cars per 1000), service (number of service centers), efficiency (number of 
kilometers per liter) and aesthetics (luster of colors). The levels of attributes, their 
weights assigned by a potential car buyer and calculated utility valuations are 
below. The resulting market shares between four brands are 27.6, 23.8, 24.2 and 
24.4 percent respectively. 
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Table 1 Attributes, weights and market shares. 



Attributes 



Brand Price Reliability Service Efficiency Aesthetics Utilities Shares 



Mitsubishi 


490 


986 


22 


12 


9 


4.127 


0.276 


Honda 


550 


989 


12 


10 


10 


3.568 


0.238 


Toyota 


520 


990 


14 


10 


9 


3.622 


0.242 


Nissan 


470 


988 


12 


12 


8 


3.656 


0.244 



Weights 

0.84 1.00 0.95 0.70 0.75 



3.2 Segmentation 

Advertising may like to address specific class of consumers. This is done by 
introducing segments into the market. We introduce the type of segments where 
every player is contained in one segment. The attribute function now takes three 
arguments: supplier, segment and attribute. The levels of attributes may actually 

differ for the same supplier between segments. 

type 

Segment 

value 

seg : Player -> Segment, 

attribute: Supplier x Segment x Attribute -> Real 

With segments we need a different way to calculate satisfaction of consumers, 
taking into account the levels of attributes advertised locally. This also affects the 
definition of the utility function. The new calculation is represented by the value 
seg_comp of type Partition: 

value 

seg_comp : Partition . (V c:Consumer, s'.Supplier, n:Nat, m:Market . 

{c,s} c m => let ss = suppliers(m) in 
seg_comp(n,c,m)(s)/n = int (utility(c,s)/total(c,ss)) end ), 
utility: Consumer x Supplier -> Real 
utility(c,s) = 

sum({attribute(s,seg(c),a) * weight(c,a) | a:Attribute . true}) 



3.3 Marketing 

The model allows us to define the marketing mix chosen by every supplier: 
price is a real number and reflects the price of the product; place is a set of 
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segments that a supplier targets in its advertising; product is a map from the 
attributes to reals and represents the levels of attributes advertised by default in all 
segments; promotion is a map from segments to reals, representing the price 

chosen specially for those segments (smaller than price): 

type 

Marketing’:: 
price: Real 
place: Segment-set 
product: Attribute Real 
promotion: Segment Real 
Marketing = {| x:Marketing’ . iswf(x)| } 



value 

iswf: Marketing’ -> Bool 
iswf(x) = price e dom product(x) A 

price(x) = product(x)(price) A dom promotion(x) = place(x) A 
(V s:Segment . s e place(x) => promotion(x)(s) < price(x)) 



4 MARKETING UNDER LIMITED RESOURCES 

So far the value of sale by suppliers was only constrained by their competitors. We 
now capture constraints that are the result of internal limitations. Two are taken 
into account: how many products a supplier is able to sell (the stock) and how 
many products a consumer can afford to buy (the budget). 

4.1 Limited Stock 

We assume that all players include a stock, a function that given a player returns 
the number of products it currently owns. Operating on the stock are usual 
functions for buying and selling. 

value 

stock : Player -> Nat 
axiom 

(V c:Consumer, n:Nat . stock(buy(n,c)) = stock(c)+n), 

(V s:Supplier, n:Nat • stock(s) > n => stock(sell(n,s)) = stock(s) - n) 

The definition of stock will affect transactions on the market. The stock of the 
supplier must be rich enough to fulfill the consumer’s demand: 
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value 

one_to_one: Nat x Consumer x Supplier x Market Market 
one_to_one(n,c,s,m) = 

m\{c,s} u {buy(n,c), sell(n,c)} pre {c,s}^ m A stock(s) 



We need similar changes to many-to-one transactions. This takes a demand, a 
consumer, a partition and a market, and produces a new market. The result is 
unspecified if the calculated share exceeds the stock of even a single supplier. 

value 

many_to_one: Nat x Consumer x Partition x Market Market 
many_to_one(n,c,p,m) = 



let c’ = buy(n,c), 

ss’ = {sell(p(n,c,m)(s),s) | siSupplier . s e m} 
in m\{c}\suppliers(m) u {c’} u ss’ end 
pre c e m A (V s:Supplier . s e m => stock(s) ^ p(n,c,m)(s)) 



4.2 Limited Budget 

We also assume that all players on the market include a budget, a function that 
given a player returns the value of money that the player currently owns. 
Operating on the budget are the functions for debiting and crediting players, 
value 

budget: Player Nat, 
credit: Nat x Supplier -> Supplier, 
debit: Nat x Consumer ^ Consumer 
axiom 

(V s:Supplier, n:Nat . budget(credit(n,s)) = budget(s)+n ), 

(V c:Consumer, n:Nat . budget(c)^n budget(debit(n,c)) = budget(c) - n) 

Every transaction will debit the consumer and credit the supplier, the price as 
advertised in the consumer’s local segment. A supplier must have enough products 
to fulfill the demand, a consumer enough money to pay. 
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value 

one_to_one: Nat x Consumer x Supplier x Market ^ Market 
one_to_one(n,c,s,m) = 
let p = int attribute(s,seg(c), price) 

in m\{c,s} ^ {buy(n,debit(n*p,c)),sell(n,credit(n*p,s))} end 
pre {c,s}c m A stock(s) ^ n A 
budget(c) ^ n * int attribute(s,seg(c), price) 

For many-to-one transactions, the amount of debit incurred by consumers must be 
calculated based on the share of the demand allocated to individual suppliers and 
the price advertised by each of them in the consumer’s segment. Function deb 
calculates this value. Likewise, cred calculates the value of credits for individual 
suppliers: 

value 

deb: Nat x Consumer x Partition x Market ^ Nat 
deb(n,c,p,m) = 

sum({p(n,c,m)(s)* int attribute(s,seg(c), price) | s:Supplier . s e m}) 
pre c e m, 



cred : Nat ^ Consumer ^ Supplier ^ Partition ^ Market -> Nat 
cred(n,c,s,p,m) = p(n,c,m)(s) * int attribute(s,seg(c), price) pre {c,s} Q m 

Suppliers must have enough products to fulfill the allocated share of the demand, a 
consumer must have enough money to pay for its demand, taken into account the 

prices of individual suppliers: 

value 

many to one: Nat x Consumer x Partition x Market ^ Market 
many_to_one(n,c,p,m) = 

let 

r = p(n,c,m), c’=buy(n,debit(deb(n,c,p,m),c)), 

ss’ = {sell(r(s), credit(cred(n,c,s,p,m), s)) | s:Supplier . s e m} 

in 

m\{c}\suppliers(m) u {c’} u ss’ end 
pre c G m A budget(c) ^ deb(n,c,p,m) A 
(V s: Supplier . s e m => stock(s) ^ p(n,c,m)(s)) 
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5 MARKETING ABSTRACTION 



Sections 2, 3 and 4 presented a sequence of increasingly elaborate models for 
enterprises competing on the single product market. We now show how to reduce 
the complexity of such models, therefore any analysis which is based upon them, 
applying abstraction. For simplicity we concentrate on the market without 
segments and its corresponding partition value comp. We introduce abstraction in 
two stages: (1) reducing a set of consumers into one and (2) reducing a set of 
suppliers into two, competing with each other. Abstraction preserves the share of 
the demand by suppliers. 



5.1 Consumer Abstraction 

Consumer abstraction is a function which produces a single consumer from the set 

of consumers, by adding up the weights for all attributes: 

value 

cabs: Consumer-set Consumer 
cabs(cc) as c’ post 

(V a:Attribute . weight(c’,a) = sum({weight(c,a) | c:Consumer . c e cc})) 

We would like this function to preserve the shares: the sum of shares received by 
every supplier from individual consumers equals the share they receive from the 
abstracted consumer, with respect to the sum of the original demands. However, 
this property is somehow optimistic given that our abstraction removed all 
distinction between consumers in terms of weights assigned to the attributes. As it 
turns out, this property is indeed true if we take demands by individual consumers 
which are inverse-proportional to their total utility values (for given set of 
suppliers on the market), say obtained by multiplying the total utility value by 
some common constant. This is written down as the following axiom which we 

can prove from the definition above: 
axiom 

(V cc:Consumer-set, d:Nat . 

(V m:Market, s:Supplier . s e m => 
let ss = suppliers(m) in 

comp(d*int total(cabs(cc),ss),cabs(cc),m)(s) = 
sum({comp(d*int total(c,ss),c,m)(s) | c:Consumer.c g cc}) 
end)) 

Then it remains to show that the total utility value for the abstracted consumer 
equals the sum of such total utilities by individual consumers. 
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axiom 

(V cc:Consumer-set, m:Market . 
let ss = suppliers(m) in 

total(cabs(cc),ss) = sum({total(c,ss) | ciConsumer . c e cc}) 
end ) 



This justifies preservation of shares by consumer abstraction, provided consumer 
demands are inverse proportional to their total utility values. 

5.2 Supplier Abstraction 

This step is to reduce the number of suppliers to two. One supplier is chosen to 
identify “our’’ enterprise. The rest is competition which we want to reduce into one 
supplier. This reduction should not change the share of consumer demand: the sum 
of what individual suppliers were able to sell before reduction should be the same 
as what the abstracted supplier is able to sell afterwards. 

value 

sabs: Supplier-set x Supplier Supplier 
sabs(ss,s) as s’ post 

(V c.'Consumer, n:Nat . comp(n,c,{s,s’})(s’)= 
sum({comp(n,c,ss u {s})(t) | tSupplier. t e ss}) 

) pre s ^ss 

We can achieve this effect by adding up the levels of attributes. The result is 
similar like before: for any consumer, the utility value of the new supplier equals 
the sum of utilities of all suppliers in the set. Unlike before, the shares before and 
after abstraction are “preserved” for any level of demand, 
axiom 

(V ss:Supplier-set, s:Supplier . s ^ ss => 

(V a:Attribute • 

attribute(sabs(ss,s),a) = sum({attribute(t,a) | t:Supplier .t e ss}))) 



6 CONCLUSIONS 

We presented a sequence of models of enterprises competing in a single-product 
market: (1) market without marketing - enterprises cannot by themselves increase 
the sale of their product; (2) marketing without limits - enterprises can increase the 
sale by advertising product attributes; (3) marketing under limited resources - 
enterprises can only make decisions within their capacity to implement them. 
Presented models are more on the side of competition than coordination: 
modelling for marketing. However, only lack of space prevented us from 
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considering more involved descriptions of the enterprise, similar like in (Janowski 
et al 1998) and extending Section 4. The paper achieved the basic frame for 
describing formally enterprises which exist on the market, their marketing 
decisions and the effect of such decisions on the sales. 

There are a number of directions we plan to proceed in future. One is to make 
the models more concrete, say to consider a multi-product market and ways to 
express and carry out production: assembly of a product from a number of 
subproducts. Another direction: although the models presented in this paper seem 
to illustrate that the marking decisions are made subject to existing resource 
constraints, it remains possible that the models allow the enterprise to actually 
determine the resource requirements of a chosen marketing mix. Last but not least, 
we would like to study the models in this paper as a way to give formal semantics 
to an application- specific language for modelling and formal analysis of 
competing (on the market) as well as cooperating enterprises. 
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Abstract 

This work describes advances in relation to previous contributions (Mannarino et 
al., 1997a, b) regarding the development of a framework for representing an 
organization through its different dimensions. The paper focuses on the 
development of Task and Dynamic models. Task models describe an organization 
from a functional point of view. They characterize the organization in terms of the 
Tasks that are carried out to achieve the enterprise goals and the way these 
activities are linked through physical and information resources and temporal 
relationships. Dynamic models depict the dynamic behavior of a production 
environment. They put emphasis on how the Resources of an organization evolve 
and interact to achieve complex goals. 
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1 INTRODUCTION 



Many strategies, such as quality improvement, business process reengineering and 
enterprise integration are currently employed by production organizations to cope 
with a highly competitive environment. Though conceptually different, they share 
one common aspect: the need to understand and describe the target organization 
through its objectives, processes, resources, costs, etc. This knowledge can be 
captured by developing different models of the organization. Models can be 
employed to describe the organization ”as-is” to evaluate its processes as well as to 
define a new or desired organization. This work describes advances in relation to 
previous contributions (Mannarino et al., 1997a, b) regarding the development of a 
language for representing an organization through its different dimensions. Task, 
Domain and Dynamic metamodels are presented as a language for enterprise 
description in terms of a vocabulary, with an associated meaning, that is combined 
according to specific syntactic rules. 

Mannarino et al. (1997a, b) focused on Domain and Task models. Domain 
models are used to identify the relevant entities of a production enterprise, to 
characterize them and to represent the static relationships among them. Task 
models describe the organization in terms of the Tasks that are carried out to 
achieve the enterprise goals and the way these activities are linked through 
physical and information resources and temporal relationships. In a Task model, 
resources may play different roles according to the behavior the task encapsulates. 

This contribution extends the Task model previously proposed (Mannarino et al., 
1997 a, b) in order to represent the fact that a Task may have various endings and 
may be carried out in different ways. Moreover, this paper focuses on dynamic 
models that describe the dynamic behavior (Ziegler, 1984) of a production 
environment. One of the proposed models is the State Transition Diagram (STD) 
that describes how a given Resource entity evolves during its life-cycle. A STD 
combines the attainable states of an object with the Tasks that can make this object 
change its state. Therefore, it specifies not only the attainable states of an object 
but also a partial order among them. In this work, the semantics of STDs is 
described and linked to Task models. 

2 COORDINATES 

2.1 Task model 

Task models are proposed as a tool for describing an organization from a functional 
point of view (Gruninger and Fox, 1994; Schreiber et al., 1993). In order to 
represent an activity that has a certain characteristic duration, the Task construct is 
employed. A Task makes use of different resources for accomplishing a set of 
goals. Resources represent both the physical and information entities of the 
organization. Therefore, a Task references the resources that are used, employed, 
created, deleted, consumed or produced during its execution. A Task may depend 
on other tasks for its execution because of the temporal order defined among tasks. 
To represent this temporal order the temporal links proposed by Allen (1983) are 
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employed: before, after, during, meets, overlaps, starts, finishes, equal and their 
converses. Moreover, a given task may depend on other tasks because these last 
tasks supply the resources the task is requiring to be carried out. Thus, the 
execution of a given Task is constrained by both the availability of its associated 
resources and by temporal links. 



Mode 

Depending on what happens during its execution, a Task can have different 
endings: (i) it can be carried out as planned, (ii) it may partially meet its goals 
because something goes wrong during its execution, (iii) it may be finished 
prematurely, etc. For instance, the Task of Controlling the quality of a batch of 
product can result in two situations, either approving or rejecting the particular 
batch. To represent the fact that a Task can have several endings, the Mode class is 
defined. Figure 1 shows some possible types of endings. A Task is associated with 
a given Mode through the task-mode-link (Figure 2). The zero or more cardinality 
at the end of the Mode construct indicates that a Task may have different endings. 
However, a Mode is associated to a unique Task. This reflects the fact that, even 
when the two different tasks have the same conceptual ending, e.g.. Meets its 
goals, the results of their execution are distinct. Moreover, as a task actually 
assumes only one final status, its associated Modes are linked through an “or- 
exclusive” structure. 




Figure 1 Different types of modes. 



Figure 2 A Task can as- 
sume different endings. 



Resource 

Tasks are chained by a set of physical and information Resources. A Resource can 
be a machine, an employee, a document, a product, etc. (see Mannarino et al., 
1997). A Resource may assume different roles, depending on the tasks in which it 
participates. To this end, the Resource? erspective (Figure 3) entity is defined. It 
represents a view of a given Resource and filters only those Resource 
characteristics that are of interest in a given context. Consider, for instance, an 
equipment item: the information that is relevant to the Engineering Department 
(functional and material characteristics) is different from the one that is important 
to the Maintenance Department (preventive plans, history of faults and corrective 
actions, shutdown periods, etc.). Similarly, the information that is pertinent to the 
Purchasing Department (alternative suppliers, technical characteristics, costs, etc.) 
is distinct from the one the Production Planning and Control Department is 
interested in {Tasks it can execute, products that can be processed, etc.). 
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Figure 3 A ResourcePerspective filters certain characteristics of a Resource. 

As shown in Figure 3, a Task references the Resource Perspectives that 
participate during its execution. The effect of a given Task over a Resource is 
actually specified by the task-resource-link (Figure 4) which generalizes the uses, 
consumes, produces, eliminates and creates links. A Resource is consumed if it is 
transformed (according to a conservation law) into one or more Resources. 
Conversely, a Resource is produced if a certain amount of it appears (according to 
a conservation law) when the Task has finished. Thus, the consumes link requires 
the existence of one or more produces links. Similarly, a Resource is used if it 
remains unchanged when the Task has finished. The creates (and its inverse 
eliminates) relationship implies that a new Resource appears in the domain 
(disappears) as a consequence of the Task execution and it is applied to those 
Resources that do not satisfy conservation laws. 

The structure of a task-resource-link encapsulates the characteristics of a 
ResourcePerspective that are relevant to a given Task. But how are these 
characteristics identified? By resorting to the concept of state. An object is defined 
by a set of slots or attributes, which take on some values. Some of these attributes 
may change their values over time as a consequence of receiving different stimuli. 
Thus, the state of a Resource is defined by a set of <attribute-value> pairs at a 
specific point in time. A Resource, and consequently a ResourcePerspective is 
associated to its possible states through the resource-state link. For a given Task to 
be performed, its associated Resources have to be at specific states, known as pre- 
states. Similarly, the Task execution may cause changes of the resource states, 
given rise to the so-called post-states. Consequently, the effects of a given Task are 
specified in terms of a set of Resources that may change their states. Figure 4 
shows that a Task actually represents its effects over a given Resource by making 
reference to specific states of the Resource: 

(i) The initial state relationship references the required state of the resource 
to participate in the task, 

(ii) T\vq final state relationship references the state the resource assumes when 
the task has finished, 

(iii) The intermediate state encapsulates the evolution of the resource during 
the task execution. 

Each type of relationship generalized in the task-resource-link {uses, consumes, 
etc.) imposes specific constraints over the states that are referenced by the initial- 
state, intermediate-state and final-state relationships. In particular, the uses link 
requires the initial and the final states of the Resource to be the same. Similarly, 
the produces link makes a Resource evolve from not existing at all to existing in a 
certain amount. Conversely, the consumes link makes a Resource evolve from 
existing in a given amount to exist in a smaller amount or to not existing at all. The 
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links creates and eliminates share the same semantics as the consumes-produces 
relationships, except that they are applicable to Resources that do not satisfy 
conservation laws. 




As it was already mentioned, a Mode (Figure 4) construct characterizes a specific 
Task ending. But how is a particular Task ending actually described? By making 
explicit the final states of the task associated Resources. Thus, a Mode is linked to 
a set of Resource states through postcondition link. 

Version 

A Task can adopt several forms in a given Mode: it can be accomplished by 
resorting to alternative Resources, different subtasks may be executed to reach the 
same goal, various methods may exist to solve the same problem, etc. Therefore, 
the TaskVersion construct is included in the language to encapsulate a particular 
decomposition task structure for carrying out a given Task under a particular Mode. 
To show the fact that a Task can reach the same final status by resorting to 
different task structures, a Mode is linked to the TaskVersion construct through the 
variant relationship (Figure 4). 

Tasks can be solved by the execution of one or more subtasks. Since the 
TaskVersion construct represents the aggregation concept that relates a Task Mode 
with a collection of subtasks, the comprises relationship links a given TaskVersion 
with the set of one or more subtasks it is decomposed into. Tasks can be 
disaggregated at any level, depending on the problem being analyzed. When the 
required level of decomposition is reached, a Task is specified in terms of a script 
or conventional procedure encapsulated in the Body class. Thus, a Task (for a given 
TaskVersion under a particular Mode) can be described in terms of either a body or 
a set of subtasks, but not simultaneously both. Therefore, the following invariant is 
associated to the Task class. 
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Invariant(Task) = (VT e Task, VB e Body, VM e Mode) 
taskrmode-link(T, M) ^ task-speciflcation(T, B) 

A TaskVersion is constrained by the use of a given set of Resources, as specified 
in the Task it implements. Moreover, TaskVersion preconditions make reference to 
those Resource states that are needed for the execution of a Task with a particular 
structure. The following rules define the relationships among a Task, the subtasks 
comprising its TaskVersion, and the set of associated Resources: 

• If a Task is an elementary one, all the Resources required for performing it 
have to be referenced by the Task. They have to be in the specified initial 
states before performing the Task. The Body construct is responsible for 
accomplishing the Task semantics by sending messages to the Task associated 
Resources. 

• If a Task is not an elementary one, it is not necessary to specify all the 
Resources related with the Task at its corresponding level of abstraction, but 
where the resources are precisely used. The place a Resource is required to be 
described is actually determined by the subtask that first makes reference to it. 
As a Mode specifies the final states of a set of Resources, it not only constrains 
the Resources that take part in its subtasks but also the Modes associated to 
these ones. Similarly, as a Resource is not necessarily specified at a given 
abstraction level, the Resource final status can be inferred by searching for 
those subtasks that ultimately have an explicit relation with the Resource. 

2.2 Dynamic models 

State Transition Diagram (STD) 

Task models represent Tasks from a static point of view; i.e., a Task is expressed in 
terms of a set of subtasks and Resources that collaborate to meet the Task goals, as 
encapsulated in the Mode construct. Dynamic models put emphasis on how a given 
Resource ^n\iiy or a set of Resource entities evolve during a given period of time 
and on how they interact to achieve Task goals. As mentioned earlier, a Task may 
change the states of the Resources it is connected to in a given model. It was also 
mentioned that the link that relates a Resource? erspective with a Task identifies 
the Resource states of interest to the Task at hand. State Transition Diagrams 
(STD) (Harel and Naamad, 1996; Harel and Gery, 1997) are employed in order to 
represent how a Resource evolves over time from state to state. Under the context 
of this contribution, a STD is defined as a digraph where nodes represent Resource 
states and arcs are labeled by messages that cause the transition of a Resource 
from a pre-state to a post-state. In turn, messages are responsible for starting and 
finishing Tasks. Thus, a STD specifies the possible sequences of Tasks that might 
affect a Resource during its life-cycle. Figure 5 shows that a Transition links a pair 
of State objects. A Resource? erspective can change its state as a consequence of a 
message that starts or finishes a given Task under a particular Mode. This change 
of state is identified by the trigger link that relates the task-resource-link with the 
Transition construct. 
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Figure 5 Dynamic metamodel. 

The cardinality of the trigger link shown in Figure 5 indicates that each task- 
resource-link may only have two associated transitions, one from the initial state 
to the intermediate one and another from this last state to the final one. As a 
TaskVersion describes a particular way of accomplishing a Task, the Resources 
that participate in a given Task may evolve through different sequences of 
intermediate states, depending on the structure of the Task. A Resource state may 
abstract many alternative scenarios. These scenarios are STDs that represent the 
Resource evolution in alternative TaskVersions. The Decomp.Alternative class is 
used to decompose a state into a particular STD. Each Decomp.Alternative is 
associated with a TaskVersion. States can be expanded to any level of detail, 
according to the number of disaggregation levels of their associated Tasks. When a 
State is disaggregated into a set of substates the semantics of such a transition is as 
follows. When a Resource evolves from a state to a composite state, it will traverse 
through the states defined by the chosen TaskVersion. The initial-state of the 
Decomp.Alternative option will be the first state the Resource will enter in. Later, 
it will evolve through the initial state successors till reaching the final-state. 
Finally, after the Resource reaches the final-state, it will traverse to the successor 
of the composite state that is defined at the upper level of abstraction. 

2.3 Example 

The following paragraph describes the Sales Order Processing scenario in an 
organization that has a production system based on a make- to-order strategy, i.e., a 
production plan is created once a week based on the Sales Orders received during 
the week. The process consists of the following activities: (i) Sales Order 
Preparation, (ii) Special- terms approval, (iii) Order Processing, (iv) Product 
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Manufacturing, (v) Quality Control, (vi) Shipping and (vii) Customer billing. A 
brief description of two of them is given below: 



(i) Sales Order Preparation: a Salesperson receives a customer call and fills out an 
electronic Sales Order Form. The form contains information such as order number, 
sales person-id, customer-account, date, product-id, description, quantity, and special 
terms. The Sales Supervisor may also receive customers' calls, in case he/she is 
available. Once the Sales Order Form has been completed, it is incorporated into a 
List of Production Orders to be Scheduled (LPOS) unless the order contains special- 
terms items, in which case the order is forwarded to the Sales Supervisor for approval 
before including it in the LPOS. This list is consulted during the week by the 
Scheduler so as to get an overall view of the production requirements and to suggest 
limits on future sales. The LPOS is a repository of the Sales Orders received during 
the week and contains for each order, customer-id, required amount, priority, desired 
reception due date, etc.. 

(ii) Special-terms evaluation: The Sales Supervisor double-checks products which have 
special terms due to quantity discounts, special sales, etc.. The special-terms can be 
authorized or rejected by the Sales Supervisor. When they are not approved, the Sales 
Supervisor contacts the customer to negotiate new conditions. If new conditions 
cannot be agreed, the sales order is canceled. Special term conditions can be accepted 
because of (i) the customer has a reliable payment history, (ii) the customer makes an 
important purchase and provides good references from other suppliers, (iii) the 
customer makes an important purchase and provides a guarantee, or (iv) new 
conditions are negotiated. 

(iii) Order Processing: 

(iv) Product Manufacturing: .... 

(v) Quality control: 

( vi) Order shipping : 

(vii) Order billing 



To show the use of the Mode concept, consider the situations that can occur 
during the Sales Order (SO) special-terms evaluation. Two alternatives can arise 
when evaluating a client sales requirement: (i) the customer sales conditions are 
accepted, and (ii) the customer sales conditions are rejected. The task Negotiate 
special terms is created to represent the Special-terms evaluation activity. Figure 6 
shows the fact that the task Negotiate special terms can have two ending status': 
SO: requirements accepted, and SO: canceled. In the latter case, the task does not 
meet its goals if the customer requirements are rejected by the Sales Supervisor 
(SS) and thus, the Sales Order is canceled. Moreover, the person responsible for 
dealing with the customer is the Sales Supervisor, as expressed by the useSj link: 
he/she needs to be available for evaluating the customer requirements, he/she will 
evolve to the state analyzing customer requir. as soon as he/she starts analyzing 
those requirements, and return to the available state when the task has finished. 
What does it mean that the Sales Supervisor is in the analyzing customer requir. 
state? To answer this question, the state needs to be disaggregated according to the 
Mode adopted for the task Negotiate special terms, as it will be discussed 
afterwards. 
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Figure 6 Special-terms requirements can be either accepted or rejected. 



Figure 7 shows that, in order to prepare a Sales Order, the task Negotiate special 
terms has to be performed, in case the Sales Order has some special sales 
conditions. This task can result in either preparing a SO or canceling it. The Sales 
Order processing specifies that the SO can be filled out by either the Sales 
Supervisor or a Sales Person. Task version Special terms exist and SalesSup. 
encapsulates the alternative in which the Sales Supervisor handles the 
communication with a customer that requires some special sales conditions. On the 
contrary, the alternative Special term exist and SalesPer. identifies the case in 
which a Sales Person handles the communication with a customer and special sales 
conditions are requested. 

As seen in the description of the Case study, special terms conditions can be 
accepted due to different reasons. To encapsulate them, the Task versions Payment 
history, Important purchase and good references, Important purchase and 
guarantee provided and Special terms initially rejected and later approved are 
created. The alternative Special terms exist and SalesPer. is disaggregated in 
Figure 7. What does characterize this alternative? The fact that (i) a Customer 
contacts a Sales Person, (ii) the Customer requires some special sales conditions, 
and (iii) these conditions are accepted by the Sales Supervisor because of the terms 
mentioned above. As the Sales Person deals with the customer, the Sales Order 
has to be forwarded to the Sales Supervisor for its evaluation. The meets 
relationship that links the tasks Fill out sales order with Forward to sales 
supervisor expresses the fact that as soon as the SO is filled out it has to be sent to 
the Sales Sup. in case it requires authorization. Furthermore, the task Negotiate 
special terms is required to accept the sales conditions no matter how one gets to it 
(through one of the Task Versions Payment history, Important purchase and Good 
references, Important purchase and Guarantee provided and Special terms initially 
rejected and later approved). 
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Figure 7 Different alternatives of the task Prepare Sales Order 

In this example, the task Prepare Sales Order modifies a particular Sales Order, 
this is equivalent to say that the Sales Order evolves from the unprepared state to 
the prepared state, passing through the in preparation state. Figure 8 shows that 
being in preparation means evolving through the series of states “empty”, “filling 
out”, “filled out and req. authorization” ... “requirements accepted”. The in 
preparation state is then a composite one that encapsulates a complex structure. 
The semantics associated with the composite state SO: in preparation is as 
follows: The composite state is entered when the task Prepare SO is started 
{Begin(modifiesl 1)). The set of substates are then chained by the subtasks of 
Prepare SO identified in the task model, starting from the initial state SO: empty 
(the first in the sequence). When the final state is reached (the one drawn with two 
concentric ellipses) the End( modifies 14) makes the SO become prepared. 

3 CONCLUSIONS 

Task models represent the processes of an organization in terms of a set of 
Resources that are transformed. The use of the Mode and Task Version concepts 
enrich the description of activities extending the aggregation relationships 
frequently used in modeling formalisms to represent different levels of detail. The 
Task model associates to each level of abstraction a set of goals (or final status) and 
preconditions that characterize the task and put constraints on its internal structure. 
These extensions to the Coordinates language are represented in the Task model 
through both the Mode construct, by considering all the relevant final endings 
associated to a Task, and the TaskVersion entity, that makes explicit all the 
alternatives of getting into these different endings. To effectively manage the 
Resources of an organization, it is necessary to identify its Resources and their 
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behaviors. The Task model has focused on the resource management by integrating 
the Resource STDs to the Tasks' descriptions. A ResourceSTD is the dynamic facet 
of models that puts emphasis on how a particular resource evolves during its life- 
cycle. Complex resource states are used to encapsulate multiple alternative 
scenarios found in a given Resource life cycle. This aggregation relationship is 
represented in the Task model by the DecompAlternative entity that links a 
Resource state with a STD, under a particular Task Version. 




Figure 8 Evolution of the resource SO when it participates in the task Prepare 
Sales Order. 
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